10 ms·

Holding a Program in One's Head (2007)

213 points by mmphosis 14y ago

gfosco 14y ago
Rings true... I definitely work best in 4-10 hour focused sessions, can easily do a weeks worth of work in one go. I can't always make those sessions happen though. Coding block? I guess I should write. [1] :) Around the time this was written, I was working somewhere you had to break all the rules to get anything accomplished. The un-sanctioned stuff was of much higher quality and function. [1] http://tommy.authpad.com/understanding-and-combatting-coder-s-block http://tommy.authpad.com/understanding-and-combatting-coder-...
dcalacci 14y ago
Not sure about working for long uninterrupted sessions(I tend to believe that short, self-scheduled breaks increase my productivity, as per the pomodoro technique), but I think the notion of loading a 'context' into your memory is spot-on. I know that, at least for me, it is difficult to even begin working on a problem unless I have that initial context in my head; without a full understanding of the problem at hand, I feel like I can't do anything well.
monsterix 14y ago
Wow, this is particularly true when you're not rapid prototyping. An aha moment happens when one is able to reverse think a complete chain of events leading up to a catastrophic failure because you saw a tiny UI/UX bug on the surface. Paul has written such splendid pieces that should resurface from time to time. This thread has happened [1] to YC community before. [1] http://news.ycombinator.com/item?id=2988835 http://news.ycombinator.com/item?id=2988835
mamontazeri 14y ago
This is very similar to how a lot of writers that do split point-of-view write their stories. "Load" all the information needed for a particular point-of-view, write all of theirs chapters, unload, and repeat.
sanxiyn 14y ago
I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering. I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it. (Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)
- nostrademons 14y ago
  We have - it's called an API. The way to work on big programs, too big to hold in your head all at once, is to break them into a bunch of little programs, each of which does something you can hide behind a simple interface. Then you hold all of the library in your head at once, and possibly repeat the same process. The complexity comes in that this really does just approximate holding the whole program in your head, and sometimes you find the API is not adequate to what you want to do. Then you're back to square one, except with a codebase that by definition is too big to hold in your head.
  - zmmmmm 14y ago
    It's also the primary driver behind the principles of object oriented programming - but those are almost dirty words these days. Somehow OO tried and failed in many ways to solve this problem, but I think it gets too little credit for at least having its heart in the right place.
    - mpweiher 14y ago
      I think OO was a first (and pretty good) stab at the problem. The primary goal was recursion, so having things be self-similar, and Alan's insight was to make the small things look like the big things (lots of little computers interacting), rather than making the big things look like the small things (everything is a function,...) http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Introduction.html http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltal... Back in 1972, we obviously didn't have a lot of "big things" (e.g. large distributed systems) to look at, so instead analogies and intuition were used. Considering, the results are not too shabby, IMHO. Nowadays we have the Interwebs, a huge distributed system that appears to work most of the time, and so one might ask if we can apply the same principle and get newer and possibly better results: if we want self-similarity, should our computations internally look like the web? We also have lots of experience with the systems we've built, and things like the Patterns books that tell us where our means of capturing common behavior fall short (if it's a pattern, it's repetitive; if it's repetitive, I should have been able to factor out the common parts). So I am not sure "failed" is the right way to describe it. As another poster pointed out, we are now capable of building much larger systems than before, and OO seems to be largely responsible for that. Another perspective is that Smalltalk (again) was never intended to be something final, but rather a basis for obsoleting itself, so describing OO as failed seems akin to calling the first stage of a Saturn V a failure because it didn't get to the moon. Where I do see a failure is that we entered an age of stagnation, and rather than see OO as a first stage to build even better things on top of, we pretty much stopped. And in that sense, I guess OO did fail, because the second and third stages that were supposed to get us to the moon didn't really get built.
kubrickslair 14y ago
In my experience, this is PG's most helpful/ reassuring technical essay. Recently I was working on/ creating pretty complex algorithms with gargantuan cobweb of edge cases. Not only did I had to work for 15+ straight hours, but in order to maintain productivity fasted (bar caffeine, few nuts & water) every alternate day to keep the steam going. Incredible times, and rather close to reaping the fruits now, but there is a pretty good chance that I would not have been here had I not read and internalized this essay- was grappling with several decades of CS research though in much less theoretical setting.
- andrewcooke 14y ago
  i'm not bashing you - i've been there myself. but that same shared experience requires me to ask: dude, how are you going to maintain that? you need to find a simpler way... if that's how you feel now, a year down the line you're going to hate that code.
  - matwood 14y ago
    dude, how are you going to maintain that? Depends on why it took 15 hours to figure out the problem and make it work. I would presume he (you) learned something during the process, so if it had to be repeated you wouldn't have the same false starts and understand the general solution much quicker. After that, comments should help the coder understand the details like edge cases and non-obvious decisions. I speak from a recent similar experience where I had to build a fairly complex piece of multi-threaded image processing code on Android. Starting out there was a lot of knowledge about image processing and Android that I simply did not know. Learning and internalizing that information took a significant chunk of time reading the docs and other peoples code. Only then could I fully understand my particular problem and implement a solution.
  - DenisM 14y ago
    Long stretches of uninterrupted thought are required to correctly partition the problem, which is a hard problem as the number of possible partitions is roughly exponential to the number of moving parts. Once the problem is optimally partitioned, understanding the solution is a linear effort. Hence, effort required to understand the problem is not indicative of the effort required to understand the solution. Now, for a new person to understand why this partitioning was preferred to all others requires one to go all the way back, and I worry can never actually be replicated, which is why old software projects often stagnate after the original architects depart.
hayksaakian 14y ago
One good test for this is if you can explain in abstract terms, and preferably to a non programmer, how the program works.
mtraven 14y ago
It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp for that very reason, but Common Lisp is 30 years old -- why hasn't the state of the art advanced since then? It's really quite shameful.
- dualogy 14y ago
  Sounds like you have a number of tangible, palpable, feasible ideas for such super-smarter next-gen programming tools -- care to share? (Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
  - ehsanu1 14y ago
    I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that it's not general purpose. But you can try reading about it if you think natural language is too ambiguous to ever possibly be a programming language. I want to write down all my thoughts about this idea, but I thought I'd get some more meat on it before I do that. Also, I haven't mentioned here why I think natural language programming can help, but I'll leave that to your imagination for now.
    - ippisl 14y ago
      One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them. [1]http://en.wikipedia.org/wiki/Controlled_natural_language http://en.wikipedia.org/wiki/Controlled_natural_language
Roybatty 14y ago
work in long stretches Nope, that idiotic open offices isn't conducive for that.
tubbo 14y ago
I completely disagree with his idea that one should hack for "36 hours straight". Not only is this extremely unhealthy for your wrists, it depletes your mental energy and will cause you to make more mistakes. I guarantee that if I managed my coding time in short 1-2 hour bursts working on the same project as Paul, given that he is working 8-16 hour shifts nonstop, that my code will not only run more efficiently but have fewer bugs. Is someone like Paul actually advocating such an idiotic and self-destructive practice? Perhaps his idea of "working on a program" also includes the time you spend thinking of it. While it's not so stupid thinking of it this way, his notion that one can achieve a higher level of productivity by working long hours are still incorrect, as many of the best ideas have come from breaking out of long coding sessions to "recalibrate" the mind and think about the problem differently.
gruseom 14y ago
I wonder what the most complex system is, to date, that has been made and that can all fit in one head. A recent example, though not a program, is Mochizuki's proposed proof of the ABC conjecture. I wonder what program would be comparable to that in complexity.
mpweiher 14y ago
To me, this goes back to the "single page program": all programs should have a top level that can be expressed as a single page of executable code and comprehensibly captures the essence of the program. If our programming language(s) don't allow for this, see what's wrong and fix it. Lather, rinse, repeat.
nnq 14y ago
You should never need to hold the entire program in your head! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" (http://www.laputan.org/mud/ http://www.laputan.org/mud/). Now it's obvious why having a big working memory makes you a great programmer - everything usually starts as a BBOM or ends up as one, but the point is to fight this tendency... Once a program grows, you should architecture it so that you only need to keep the piece that you're working on in your head, ie it should be a network of black-boxes and you should only need to open the one you're currently working at, and even when you do things like large scale refactoring, you should be able to selectively and partially open only some of the boxes to do your job - and this is what programming languages and patterns should help you do!
- manmal 14y ago
  To avoid "memory overload", I have taken to literally ignoring parts of the system which I currently don't need. I.e., I don't even look at other classes' code before I don't need them. Else, I would have to spend 3 days of understanding it all. That's for very big programs, and of course I do look at the overall structure and what patterns have been used to couple classes together. But if a method promises something with a contract, I won't read through it, but treat it as a black box. My theory is that cognitive power is like money spent during the day. I can recharge it after a few hours by taking a nap of 20 minutes, but I better watch what I expend my cognitive credits for. And spending it all on reading other people's code (which has probably already been revised 10 times) is not worth it.
  - nnq 14y ago
    ...this is what we all try to do I guess. You said "I don't even look at other classes' code" but I always find it much easier to not look at a function's code or at the code of a method of an immutable object or a "predicatively mutable" objects than for classes of highly mutable objects. ...that's why I'm currently investigating functional programming as way to make it easier to hold larger parts of programs in your head.
barking 14y ago
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. This is so true for me. And not just for big complex programs but also for anything not completely trivial. The one (applicable to me) part of the joel test (http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html) that I never made any progress on was having a spec. I just couldn't do it whether through laziness, inability to concentrate or whatever. Actually it's been a bit of a guilty secret of mine. Generally there'll be some part of the program that I'll be able to solve right away and while I'm doing that I'll be having ideas about how to do something else. Later it might become obvious that a certain part would have been better done another way and if there's a serious benefit to changing things I can do it at that stage. It's only after a lot of work's already been done that I'd be able to produce some kind of spec for the program Having a spec that lays everything out beforehand is to me analagous to a mathematician writing the final proof of a theorem before doing all the thinking.
juliangamble 14y ago
Rich Hickey made some very similar points in his Strange Loop presentation "Simple Made Easy" http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
nnq 14y ago
> Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable. ...reread the whole thing and this thing got my imagination "high" ...I feel there's some deep wisdom in here ...maybe we do thing wrong in most of our organizations by requiring complex components like people to be interchangeable, instead of accepting the fact that they are not and that the "personality" of an organization should be allowed to radically change as people (or bigger "unique" subsystems) become part of it or leave it... maybe we could even end up with what Nassim Taleb calls "antifragile" organizations...
- saraid216 14y ago
  It's not just the "personality", though. It's also the idea that if your sysadmin gets hit by a bus, your site doesn't become unusable.
  - nnq 14y ago
    yep, the compromise is probably to separate maintenance from creative tasks, and accept that maintenance tasks need replaceable components, but then again, maybe it's ok to accept things like having a certain software component written by a "lone wolf eccentric genius" in a dialect of lisp he alone can understand (replace with your fav equivalent phrase) as the price for having really unique features and performance for that component that no competitor can match, and make contingencies for the risk of having to throw away that codebase and rewrite from scratch if he gets hit by a bus... maybe if the APIs and interfaces are properly designed (or processes or however else you may call then in peopleware land), you can accept working with unique and not easily replaceable components and somehow design systems that are architected to embrace the "hit by a bus" type of risks ...and if I think further along these line, the organization that can best afford these types of risks are big software corporations (think Google, Microsoft) that could afford to scrap entire codebases and projects (if they ever got over the "mind brakes" that make the managers consider such things insane), or start things in completely new directions when they bring new "genius visionaries" ...these types of innovation based on risky and irreplaceable components/people would be prohibitively expensive or impossible for start-ups, but may bring us new breakthroughs in things like general purpose AI or god know what ...maybe true progress really is the work of unique individuals and our whole focus on "team work" and "replaceable peopleware" is what suffocates and kills innovation
Spearchucker 14y ago
Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution, or at the component level, where one specific aspect is dealt with. That minimizes the amount of stuff the programmer needs to hold in his head. If you find yourself oscillating between higher and lower levels of abstraction you should probably be revisiting your architecture. It's called separation of concerns. No tool improvement is going to solve that. Neither will a rethink of ways of working.
- batgaijin 14y ago
  What about Haskell? The type system tells you exactly what's going on.
  - Spearchucker 14y ago
    Some tools are better than others. I'm not familiar with Haskell but can tell you that in the .NET world LINQ is bad, because it forces the melding of process components with data access logic.
    - batgaijin 14y ago
      Haskell has it's own warts of course, but the functional straightjacket you're forced into makes it very easy to understand the scope of a computation.
- chubot 14y ago
  That's begging the question. To come up with the abstractions in the first place requires understanding the whole problem. There's no getting around this. I can't tell you how many programs I've seen where the wrong abstraction is never perturbed, and as a result all feature development pays a huge cost in reliability and functionality. To create or change an abstraction, you have to get your mind around all sides of it. That requires A LOT of context. You should always be "revisiting your architecture". It's basically never true that the first architecture works, unless you've written an extremely similar program before. The worst programs result when people are afraid to shift boundaries. That happens a lot in big company development that PG talks about -- each team just accumulates crud on their side of the abstraction boundary, but they never talk to each other so they can globally simplify. It's true that abstraction reduces complexity, and thus is the only way you can build big programs, but it takes a lot of hard work to get there.
jrogers65 14y ago
For years now I have been arguing with other programmers on the merits of IDE features such as intellisense. My position has always been that they are completely unnecessary. Autocomplete is useful, sure, since it saves some typing, but that is it's primary goal - to save keystrokes, not to help you remember what a class is capable of doing. Many programmers appear to get caught up in the small picture way of thinking, where all that they consider important is the code they are currently working on. The fact of the matter is that a piece of software is an ecosystem. Every part of it is directly or indirectly tied to every other part. It is only when we consider the system as a whole that we can create an elegant architecture. This is simply not possible if things are always seen as units and their relationships are an afterthought. Thank you for this link. I shall be using it to add fuel to any future arguments along these lines. EDIT: Clearly, it takes a lot of effort and skill to pull this off. The bottleneck becomes the human. The logical question that follows is 'how do we make the human more efficient and capable of remembering more?'. The answer is diet, nootropics, meditation, exercise and knowledge of techniques (e.g. how to memorise facts rapidly). I won't go into specifics but suffice it to say that most people are undernourished and are mentally impaired because of it.
- charlieflowers 14y ago
  >>>> "The answer is diet, nootropics, meditation, exercise and knowledge of techniques (e.g. how to memorise facts rapidly). I won't go into specifics but suffice it to say that most people are undernourished and are mentally impaired because of it." Dude, if you have some concrete insights in these areas, you definitely should go into specifics. A lot of us would be very interested.
  - jrogers65 14y ago
    My apologies, I thought that it was outside of the context of the conversation. A surprisingly high percentage of people have nutritional deficiencies. For example, an alarmingly high percentage of people in the US are deficient in Magnesium, an essential nutrient (meaning that your body cannot manufacture it). http://en.wikipedia.org/wiki/Magnesium_deficiency_%28medicine%29 http://en.wikipedia.org/wiki/Magnesium_deficiency_%28medicin... > 57% of the US population does not meet the US RDA for levels of magnesium And we're talking about a first-world country here! Magnesium is essential for a healthy stress response, and, as we probably know from experience, many people struggle with the stresses of day to day life. Anybody who regularly consumes alcohol, tobacco or caffeine is likely to be deficient as those drugs rapidly deplete Mg reserves in the body. That is just one example. Another is Calcium, which 75% of people have deficiency of (http://www.livestrong.com/article/365193-heart-disease-caused-by-calcium-deficiency/ http://www.livestrong.com/article/365193-heart-disease-cause...). The body also becomes less efficient as time goes on. Have you ever wondered by old people tend to be more grumpy than everybody else? Because our serotonin (a neurotransmitter which is implicated in mood and irritability) levels fall as we age - http://www.pslgroup.com/dg/4098E.htm http://www.pslgroup.com/dg/4098E.htm One way to offset the brain's natural decline of neurotransmitters is to supplement with the precursor amino acids which are used to manufacture those neurotransmitters. For example, L-Tryptophan, an essential (again, meaning that you cannot make it) amino acid is rapidly absorbed by the body and is used to make more serotonin (among other things). The difference between protein and straight amino acids is that the latter are ready for use, whereas proteins, which are composed of amino acids, need to be broken down to their constituent parts before the body can use them. Another age-related neurotransmitter decline - dopamine. A lot of older people have had some success with using D,L-Phenylalanine and L-Tyrosine to boost dopamine levels and reclaim their sex drive. Healthy acetylcholine levels are also essential for cognition and can be boosted with things containing Choline (eggs are an excellent source). GABA levels are very important for short term memory and focus. For example, anyone who drinks coffee will have experienced that overexcited state where you have a mountain of motivation but lack proper focus. Taking L-Theanine (Green Tea also contains this), an amino acid which causes increases GABA levels will restore the focus. I never drink coffee without L-Theanine for this reason. Taking L-Glutamine prior to drinking alcohol will prevent a hangover. It will also stop alcohol and sugar cravings. This is because the body is capable of using L-Glutamine as a source of energy. But the most important thing is how all of these neurotransmitters interact with each other. Some of them are polar opposites, some modulate the release/inhibition of others. The brain is always striving for balance (homeostasis). All of these neurotransmitters, nutrients and minerals are vectors which pull it in one direction or another. Keeping them in balance is the key to feeling good. Having a model of their interactions makes it considerably easier to debug problems and fix them. This comes with experimenting with your body and gaining an intuitive understanding of what's what. I think that it would be difficult to come up with a generalised approach due to people's baseline levels of each neurotransmitter being different. Note that even popular multivitamin brands sometimes contain too little of a given nutrient. I recently bought a doctor-recommended one and it barely contains and magnesium or calcium. It pays to educate yourself and not to completely defer your health to someone else. It's your body and it's essentially your problem. After addressing deficiencies, I found that I felt a lot better and that my rate of recovery from stress, a night of drinking or strenuous physical activity had improved considerably. Another important factor is removing things which cause harm. E.g. alcohol, in sufficiently high doses (high enough to be drunk), is neurotoxic, meaning that it directly harms the brain. One of the primary mechanisms of alcoholism is that the damage caused by alcohol directly contributes to future alcohol cravings. A lot of people have problems with anxiety - they would be wise to discontinue caffeine intake altogether as it is a major risk factor in anxiety disorders. Meditation has a host of benefits and structural changes have been observed in the brains of practitioners - http://www.scientificamerican.com/podcast/episode.cfm?id=mediation-correlated-with-structura-11-01-22 http://www.scientificamerican.com/podcast/episode.cfm?id=med... Exercise is absolutely essential and, frankly, should be a first-line treatment for things such as depression. There are also a few new and interesting nootropic substances such as Piracetam, Aniracetam and Noopept, the last one being the most effective for me personally. All the wise folk say that the body should be treated like a temple. I completely agree with them since the mind and the body are but one and the same. Treat the body right and the mind will follow. Treat the mind right and you will feel right.
skrebbel 14y ago
I'm not so sure about the "don't touch other people's code, and don't allow them to touch yours" bit. What if someone gets hit by a truck? Or leaves the company? Or shrug makes a promotion? I've been pretty comfortable about the "collective code ownership" approach, within small enough teams, in the last 4 years. You can talk issues over with a colleague and he knows what you're on about, code reviews become effective, and getting something important changed does not mean you have to wait for the 'owner' to have time for it. What's wrong with that?
- almog 14y ago
  Exactly what I thought - I only 'own' the code if it's a topic branch, once my peers reviewed it, they should know it as much as I do.
Munksgaard 14y ago
Peter Naur wrote on this subject in 85 and came to much the same conclusions. Here is the paper for anyone interested http://www.google.dk/url?sa=t&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.itu.dk%2Fcourses%2FSASU%2FF2010%2Ffiles%2FNaur%2520from%2520Cockburn.pdf&ei=cEjDUJbyFsPj4QS4kYH4Ag&usg=AFQjCNGsZkpSqx_WTO7E-lm_bGSiv-L5Gg&sig2=bdpslbjKCzqdiIVEF262kA http://www.google.dk/url?sa=t&source=web&cd=1&ve...
biggs 14y ago
Are there any applications (mobile, web or whatever) whose sole purpose is to help a programmer capture the program that is in his/her head? The first thing that comes to mind is UML based applications like Rational Rose. But those seem to have such high barriers of entry and are more geared towards communicating the program to other developers or different stakeholders.
alcuadrado 14y ago
This is totally misleading, and may make people feel they are not good at programming. To quote one of the masters of CS: The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. Dijkstra (1972) The Humble Programmer (EWD340)
stcredzero 14y ago
Holding a large program in your head is like holding a city in your head. You can't entirely do it. What you can do is to know broad outlines and principles, so you can navigate to the relevant points and negotiate difficult parts. When you see the details at the relevant places, then you can deal with them. It's like being a cab driver. You don't memorize every cobblestone and pothole, but you know how to get where you need to go you can deal with them as you're driving.
- JoeAltmaier 14y ago
  You can visit the neighborhoods often enough that they are quickly familiar when you happen upon them again. That's called a domain expert. In fact, London cab drivers DO hold the city in their head. They are required to, before they get their license.
  - stcredzero 14y ago
    Yes, I was thinking about what I read about London cabbies. However, they don't necessarily have recall of every pothole and cobblestone. They remember enough of a map so they can get to where they need to be, and deal with what's there on the way.
slant 14y ago
I find it interesting to read this again after a few years only to realize that Paul is in direct contradiction of those who would have us take a break every 25 minutes with his second point. It's kinda refreshing to hear this point of view again. I worked 5 solid hours last night, starting that particular stretch around 7pm and got around 3-4 normal work days worth of work done.
- zipdog 14y ago
  Yesterday a friend explained the physiological reasons behind 25 minute breaks: basically the muscles (including eye muscles) go into a different state of relaxed-tension and its generally not good for them to be in that state while the body is sitting-looking. There's also the issue of the effort required to concentrate on a task, which gives diminishing returns as you extend it beyond ~25 minutes without break. However a mental flow state (what you seem to describe) requires little to no concentration effort and so can yield great returns over the time spent. The tradeoff is that the body is in a less-than-desirable muscular situation for a prolonged time - but I'm guessing the damage there is not so significant if 8 hour flow sessions are not a daily habit. tl;dr: the 25 minute break thing is probably a good general guide, but shouldn't stop you pulling an 8 hour session if you are absorbed and productive
njx 14y ago
I do it. I build mockups in my mind, run through clicks and interactions and finally the code flows.
w_t_payne 14y ago
Perhaps the key to a productive software industry is - paradoxically - to de-industrialize. Model the organization and communications patterns on a guild of independent workshops, each workshop comprising one artisan developer with one or two apprentice developers, with each workshop supplying hyper-specialized services based around a library of existing, re-deployable functionality.
8ig8 14y ago
I just came across this article in a HN post last week that was discussing a similar theme. I think it does a great job explaining the challenges of beings programmer... http://alexthunder.livejournal.com/309815.html http://alexthunder.livejournal.com/309815.html
- irishcoffee 14y ago
  This is a fantastic summary, and I thank you for sharing.

213 points by mmphosis 14y ago

Rings true... I definitely work best in 4-10 hour focused sessions, can easily do a weeks worth of work in one go. I can't always make those sessions happen though. Coding block? I guess I should write. [1] :) Around the time this was written, I was working somewhere you had to break all the rules to get anything accomplished. The un-sanctioned stuff was of much higher quality and function. [1] http://tommy.authpad.com/understanding-and-combatting-coder-s-block http://tommy.authpad.com/understanding-and-combatting-coder-...

dcalacci 14y ago

Not sure about working for long uninterrupted sessions(I tend to believe that short, self-scheduled breaks increase my productivity, as per the pomodoro technique), but I think the notion of loading a 'context' into your memory is spot-on. I know that, at least for me, it is difficult to even begin working on a problem unless I have that initial context in my head; without a full understanding of the problem at hand, I feel like I can't do anything well.

monsterix 14y ago

Wow, this is particularly true when you're not rapid prototyping. An aha moment happens when one is able to reverse think a complete chain of events leading up to a catastrophic failure because you saw a tiny UI/UX bug on the surface. Paul has written such splendid pieces that should resurface from time to time. This thread has happened [1] to YC community before. [1] http://news.ycombinator.com/item?id=2988835 http://news.ycombinator.com/item?id=2988835

mamontazeri 14y ago

This is very similar to how a lot of writers that do split point-of-view write their stories. "Load" all the information needed for a particular point-of-view, write all of theirs chapters, unload, and repeat.

sanxiyn 14y ago

I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering. I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it. (Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)

nostrademons 14y ago
We have - it's called an API. The way to work on big programs, too big to hold in your head all at once, is to break them into a bunch of little programs, each of which does something you can hide behind a simple interface. Then you hold all of the library in your head at once, and possibly repeat the same process. The complexity comes in that this really does just approximate holding the whole program in your head, and sometimes you find the API is not adequate to what you want to do. Then you're back to square one, except with a codebase that by definition is too big to hold in your head.
- zmmmmm 14y ago
  It's also the primary driver behind the principles of object oriented programming - but those are almost dirty words these days. Somehow OO tried and failed in many ways to solve this problem, but I think it gets too little credit for at least having its heart in the right place.
  - mpweiher 14y ago
    I think OO was a first (and pretty good) stab at the problem. The primary goal was recursion, so having things be self-similar, and Alan's insight was to make the small things look like the big things (lots of little computers interacting), rather than making the big things look like the small things (everything is a function,...) http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Introduction.html http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltal... Back in 1972, we obviously didn't have a lot of "big things" (e.g. large distributed systems) to look at, so instead analogies and intuition were used. Considering, the results are not too shabby, IMHO. Nowadays we have the Interwebs, a huge distributed system that appears to work most of the time, and so one might ask if we can apply the same principle and get newer and possibly better results: if we want self-similarity, should our computations internally look like the web? We also have lots of experience with the systems we've built, and things like the Patterns books that tell us where our means of capturing common behavior fall short (if it's a pattern, it's repetitive; if it's repetitive, I should have been able to factor out the common parts). So I am not sure "failed" is the right way to describe it. As another poster pointed out, we are now capable of building much larger systems than before, and OO seems to be largely responsible for that. Another perspective is that Smalltalk (again) was never intended to be something final, but rather a basis for obsoleting itself, so describing OO as failed seems akin to calling the first stage of a Saturn V a failure because it didn't get to the moon. Where I do see a failure is that we entered an age of stagnation, and rather than see OO as a first stage to build even better things on top of, we pretty much stopped. And in that sense, I guess OO did fail, because the second and third stages that were supposed to get us to the moon didn't really get built.

kubrickslair 14y ago

In my experience, this is PG's most helpful/ reassuring technical essay. Recently I was working on/ creating pretty complex algorithms with gargantuan cobweb of edge cases. Not only did I had to work for 15+ straight hours, but in order to maintain productivity fasted (bar caffeine, few nuts & water) every alternate day to keep the steam going. Incredible times, and rather close to reaping the fruits now, but there is a pretty good chance that I would not have been here had I not read and internalized this essay- was grappling with several decades of CS research though in much less theoretical setting.

andrewcooke 14y ago
i'm not bashing you - i've been there myself. but that same shared experience requires me to ask: dude, how are you going to maintain that? you need to find a simpler way... if that's how you feel now, a year down the line you're going to hate that code.
- matwood 14y ago
  dude, how are you going to maintain that? Depends on why it took 15 hours to figure out the problem and make it work. I would presume he (you) learned something during the process, so if it had to be repeated you wouldn't have the same false starts and understand the general solution much quicker. After that, comments should help the coder understand the details like edge cases and non-obvious decisions. I speak from a recent similar experience where I had to build a fairly complex piece of multi-threaded image processing code on Android. Starting out there was a lot of knowledge about image processing and Android that I simply did not know. Learning and internalizing that information took a significant chunk of time reading the docs and other peoples code. Only then could I fully understand my particular problem and implement a solution.
- DenisM 14y ago
  Long stretches of uninterrupted thought are required to correctly partition the problem, which is a hard problem as the number of possible partitions is roughly exponential to the number of moving parts. Once the problem is optimally partitioned, understanding the solution is a linear effort. Hence, effort required to understand the problem is not indicative of the effort required to understand the solution. Now, for a new person to understand why this partitioning was preferred to all others requires one to go all the way back, and I worry can never actually be replicated, which is why old software projects often stagnate after the original architects depart.

hayksaakian 14y ago

One good test for this is if you can explain in abstract terms, and preferably to a non programmer, how the program works.

mtraven 14y ago

It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp for that very reason, but Common Lisp is 30 years old -- why hasn't the state of the art advanced since then? It's really quite shameful.

dualogy 14y ago
Sounds like you have a number of tangible, palpable, feasible ideas for such super-smarter next-gen programming tools -- care to share? (Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)
- ehsanu1 14y ago
  I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that it's not general purpose. But you can try reading about it if you think natural language is too ambiguous to ever possibly be a programming language. I want to write down all my thoughts about this idea, but I thought I'd get some more meat on it before I do that. Also, I haven't mentioned here why I think natural language programming can help, but I'll leave that to your imagination for now.
  - ippisl 14y ago
    One way to solve the ambiguity problem of natural languages is using a controlled natural language, which is a limited subset of a natural language[1]. Some of those are machine transformable to logic. There's even some work to encode legal knowledge using them. [1]http://en.wikipedia.org/wiki/Controlled_natural_language http://en.wikipedia.org/wiki/Controlled_natural_language

Roybatty 14y ago

work in long stretches Nope, that idiotic open offices isn't conducive for that.

tubbo 14y ago

I completely disagree with his idea that one should hack for "36 hours straight". Not only is this extremely unhealthy for your wrists, it depletes your mental energy and will cause you to make more mistakes. I guarantee that if I managed my coding time in short 1-2 hour bursts working on the same project as Paul, given that he is working 8-16 hour shifts nonstop, that my code will not only run more efficiently but have fewer bugs. Is someone like Paul actually advocating such an idiotic and self-destructive practice? Perhaps his idea of "working on a program" also includes the time you spend thinking of it. While it's not so stupid thinking of it this way, his notion that one can achieve a higher level of productivity by working long hours are still incorrect, as many of the best ideas have come from breaking out of long coding sessions to "recalibrate" the mind and think about the problem differently.

gruseom 14y ago

I wonder what the most complex system is, to date, that has been made and that can all fit in one head. A recent example, though not a program, is Mochizuki's proposed proof of the ABC conjecture. I wonder what program would be comparable to that in complexity.

mpweiher 14y ago

To me, this goes back to the "single page program": all programs should have a top level that can be expressed as a single page of executable code and comprehensibly captures the essence of the program. If our programming language(s) don't allow for this, see what's wrong and fix it. Lather, rinse, repeat.

nnq 14y ago

You should never need to hold the entire program in your head! (except when you actually begin coding it - for this early stage of development I agree with PG). Needing to hold a whole mature program in your head every time you work on it is a code smell that tells you your solution ended up in the shape of the most popular software architecture of all time: the "big ball of mud" (http://www.laputan.org/mud/ http://www.laputan.org/mud/). Now it's obvious why having a big working memory makes you a great programmer - everything usually starts as a BBOM or ends up as one, but the point is to fight this tendency... Once a program grows, you should architecture it so that you only need to keep the piece that you're working on in your head, ie it should be a network of black-boxes and you should only need to open the one you're currently working at, and even when you do things like large scale refactoring, you should be able to selectively and partially open only some of the boxes to do your job - and this is what programming languages and patterns should help you do!

manmal 14y ago
To avoid "memory overload", I have taken to literally ignoring parts of the system which I currently don't need. I.e., I don't even look at other classes' code before I don't need them. Else, I would have to spend 3 days of understanding it all. That's for very big programs, and of course I do look at the overall structure and what patterns have been used to couple classes together. But if a method promises something with a contract, I won't read through it, but treat it as a black box. My theory is that cognitive power is like money spent during the day. I can recharge it after a few hours by taking a nap of 20 minutes, but I better watch what I expend my cognitive credits for. And spending it all on reading other people's code (which has probably already been revised 10 times) is not worth it.
- nnq 14y ago
  ...this is what we all try to do I guess. You said "I don't even look at other classes' code" but I always find it much easier to not look at a function's code or at the code of a method of an immutable object or a "predicatively mutable" objects than for classes of highly mutable objects. ...that's why I'm currently investigating functional programming as way to make it easier to hold larger parts of programs in your head.

barking 14y ago

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. This is so true for me. And not just for big complex programs but also for anything not completely trivial. The one (applicable to me) part of the joel test (http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html) that I never made any progress on was having a spec. I just couldn't do it whether through laziness, inability to concentrate or whatever. Actually it's been a bit of a guilty secret of mine. Generally there'll be some part of the program that I'll be able to solve right away and while I'm doing that I'll be having ideas about how to do something else. Later it might become obvious that a certain part would have been better done another way and if there's a serious benefit to changing things I can do it at that stage. It's only after a lot of work's already been done that I'd be able to produce some kind of spec for the program Having a spec that lays everything out beforehand is to me analagous to a mathematician writing the final proof of a theorem before doing all the thinking.

juliangamble 14y ago

Rich Hickey made some very similar points in his Strange Loop presentation "Simple Made Easy" http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

nnq 14y ago

> Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable. ...reread the whole thing and this thing got my imagination "high" ...I feel there's some deep wisdom in here ...maybe we do thing wrong in most of our organizations by requiring complex components like people to be interchangeable, instead of accepting the fact that they are not and that the "personality" of an organization should be allowed to radically change as people (or bigger "unique" subsystems) become part of it or leave it... maybe we could even end up with what Nassim Taleb calls "antifragile" organizations...

saraid216 14y ago
It's not just the "personality", though. It's also the idea that if your sysadmin gets hit by a bus, your site doesn't become unusable.
- nnq 14y ago
  yep, the compromise is probably to separate maintenance from creative tasks, and accept that maintenance tasks need replaceable components, but then again, maybe it's ok to accept things like having a certain software component written by a "lone wolf eccentric genius" in a dialect of lisp he alone can understand (replace with your fav equivalent phrase) as the price for having really unique features and performance for that component that no competitor can match, and make contingencies for the risk of having to throw away that codebase and rewrite from scratch if he gets hit by a bus... maybe if the APIs and interfaces are properly designed (or processes or however else you may call then in peopleware land), you can accept working with unique and not easily replaceable components and somehow design systems that are architected to embrace the "hit by a bus" type of risks ...and if I think further along these line, the organization that can best afford these types of risks are big software corporations (think Google, Microsoft) that could afford to scrap entire codebases and projects (if they ever got over the "mind brakes" that make the managers consider such things insane), or start things in completely new directions when they bring new "genius visionaries" ...these types of innovation based on risky and irreplaceable components/people would be prohibitively expensive or impossible for start-ups, but may bring us new breakthroughs in things like general purpose AI or god know what ...maybe true progress really is the work of unique individuals and our whole focus on "team work" and "replaceable peopleware" is what suffocates and kills innovation

Spearchucker 14y ago

Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution, or at the component level, where one specific aspect is dealt with. That minimizes the amount of stuff the programmer needs to hold in his head. If you find yourself oscillating between higher and lower levels of abstraction you should probably be revisiting your architecture. It's called separation of concerns. No tool improvement is going to solve that. Neither will a rethink of ways of working.

batgaijin 14y ago
What about Haskell? The type system tells you exactly what's going on.
- Spearchucker 14y ago
  Some tools are better than others. I'm not familiar with Haskell but can tell you that in the .NET world LINQ is bad, because it forces the melding of process components with data access logic.
  - batgaijin 14y ago
    Haskell has it's own warts of course, but the functional straightjacket you're forced into makes it very easy to understand the scope of a computation.
chubot 14y ago
That's begging the question. To come up with the abstractions in the first place requires understanding the whole problem. There's no getting around this. I can't tell you how many programs I've seen where the wrong abstraction is never perturbed, and as a result all feature development pays a huge cost in reliability and functionality. To create or change an abstraction, you have to get your mind around all sides of it. That requires A LOT of context. You should always be "revisiting your architecture". It's basically never true that the first architecture works, unless you've written an extremely similar program before. The worst programs result when people are afraid to shift boundaries. That happens a lot in big company development that PG talks about -- each team just accumulates crud on their side of the abstraction boundary, but they never talk to each other so they can globally simplify. It's true that abstraction reduces complexity, and thus is the only way you can build big programs, but it takes a lot of hard work to get there.

jrogers65 14y ago

For years now I have been arguing with other programmers on the merits of IDE features such as intellisense. My position has always been that they are completely unnecessary. Autocomplete is useful, sure, since it saves some typing, but that is it's primary goal - to save keystrokes, not to help you remember what a class is capable of doing. Many programmers appear to get caught up in the small picture way of thinking, where all that they consider important is the code they are currently working on. The fact of the matter is that a piece of software is an ecosystem. Every part of it is directly or indirectly tied to every other part. It is only when we consider the system as a whole that we can create an elegant architecture. This is simply not possible if things are always seen as units and their relationships are an afterthought. Thank you for this link. I shall be using it to add fuel to any future arguments along these lines. EDIT: Clearly, it takes a lot of effort and skill to pull this off. The bottleneck becomes the human. The logical question that follows is 'how do we make the human more efficient and capable of remembering more?'. The answer is diet, nootropics, meditation, exercise and knowledge of techniques (e.g. how to memorise facts rapidly). I won't go into specifics but suffice it to say that most people are undernourished and are mentally impaired because of it.

charlieflowers 14y ago
>>>> "The answer is diet, nootropics, meditation, exercise and knowledge of techniques (e.g. how to memorise facts rapidly). I won't go into specifics but suffice it to say that most people are undernourished and are mentally impaired because of it." Dude, if you have some concrete insights in these areas, you definitely should go into specifics. A lot of us would be very interested.
- jrogers65 14y ago
  My apologies, I thought that it was outside of the context of the conversation. A surprisingly high percentage of people have nutritional deficiencies. For example, an alarmingly high percentage of people in the US are deficient in Magnesium, an essential nutrient (meaning that your body cannot manufacture it). http://en.wikipedia.org/wiki/Magnesium_deficiency_%28medicine%29 http://en.wikipedia.org/wiki/Magnesium_deficiency_%28medicin... > 57% of the US population does not meet the US RDA for levels of magnesium And we're talking about a first-world country here! Magnesium is essential for a healthy stress response, and, as we probably know from experience, many people struggle with the stresses of day to day life. Anybody who regularly consumes alcohol, tobacco or caffeine is likely to be deficient as those drugs rapidly deplete Mg reserves in the body. That is just one example. Another is Calcium, which 75% of people have deficiency of (http://www.livestrong.com/article/365193-heart-disease-caused-by-calcium-deficiency/ http://www.livestrong.com/article/365193-heart-disease-cause...). The body also becomes less efficient as time goes on. Have you ever wondered by old people tend to be more grumpy than everybody else? Because our serotonin (a neurotransmitter which is implicated in mood and irritability) levels fall as we age - http://www.pslgroup.com/dg/4098E.htm http://www.pslgroup.com/dg/4098E.htm One way to offset the brain's natural decline of neurotransmitters is to supplement with the precursor amino acids which are used to manufacture those neurotransmitters. For example, L-Tryptophan, an essential (again, meaning that you cannot make it) amino acid is rapidly absorbed by the body and is used to make more serotonin (among other things). The difference between protein and straight amino acids is that the latter are ready for use, whereas proteins, which are composed of amino acids, need to be broken down to their constituent parts before the body can use them. Another age-related neurotransmitter decline - dopamine. A lot of older people have had some success with using D,L-Phenylalanine and L-Tyrosine to boost dopamine levels and reclaim their sex drive. Healthy acetylcholine levels are also essential for cognition and can be boosted with things containing Choline (eggs are an excellent source). GABA levels are very important for short term memory and focus. For example, anyone who drinks coffee will have experienced that overexcited state where you have a mountain of motivation but lack proper focus. Taking L-Theanine (Green Tea also contains this), an amino acid which causes increases GABA levels will restore the focus. I never drink coffee without L-Theanine for this reason. Taking L-Glutamine prior to drinking alcohol will prevent a hangover. It will also stop alcohol and sugar cravings. This is because the body is capable of using L-Glutamine as a source of energy. But the most important thing is how all of these neurotransmitters interact with each other. Some of them are polar opposites, some modulate the release/inhibition of others. The brain is always striving for balance (homeostasis). All of these neurotransmitters, nutrients and minerals are vectors which pull it in one direction or another. Keeping them in balance is the key to feeling good. Having a model of their interactions makes it considerably easier to debug problems and fix them. This comes with experimenting with your body and gaining an intuitive understanding of what's what. I think that it would be difficult to come up with a generalised approach due to people's baseline levels of each neurotransmitter being different. Note that even popular multivitamin brands sometimes contain too little of a given nutrient. I recently bought a doctor-recommended one and it barely contains and magnesium or calcium. It pays to educate yourself and not to completely defer your health to someone else. It's your body and it's essentially your problem. After addressing deficiencies, I found that I felt a lot better and that my rate of recovery from stress, a night of drinking or strenuous physical activity had improved considerably. Another important factor is removing things which cause harm. E.g. alcohol, in sufficiently high doses (high enough to be drunk), is neurotoxic, meaning that it directly harms the brain. One of the primary mechanisms of alcoholism is that the damage caused by alcohol directly contributes to future alcohol cravings. A lot of people have problems with anxiety - they would be wise to discontinue caffeine intake altogether as it is a major risk factor in anxiety disorders. Meditation has a host of benefits and structural changes have been observed in the brains of practitioners - http://www.scientificamerican.com/podcast/episode.cfm?id=mediation-correlated-with-structura-11-01-22 http://www.scientificamerican.com/podcast/episode.cfm?id=med... Exercise is absolutely essential and, frankly, should be a first-line treatment for things such as depression. There are also a few new and interesting nootropic substances such as Piracetam, Aniracetam and Noopept, the last one being the most effective for me personally. All the wise folk say that the body should be treated like a temple. I completely agree with them since the mind and the body are but one and the same. Treat the body right and the mind will follow. Treat the mind right and you will feel right.

skrebbel 14y ago

I'm not so sure about the "don't touch other people's code, and don't allow them to touch yours" bit. What if someone gets hit by a truck? Or leaves the company? Or shrug makes a promotion? I've been pretty comfortable about the "collective code ownership" approach, within small enough teams, in the last 4 years. You can talk issues over with a colleague and he knows what you're on about, code reviews become effective, and getting something important changed does not mean you have to wait for the 'owner' to have time for it. What's wrong with that?

almog 14y ago
Exactly what I thought - I only 'own' the code if it's a topic branch, once my peers reviewed it, they should know it as much as I do.

Munksgaard 14y ago

Peter Naur wrote on this subject in 85 and came to much the same conclusions. Here is the paper for anyone interested http://www.google.dk/url?sa=t&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.itu.dk%2Fcourses%2FSASU%2FF2010%2Ffiles%2FNaur%2520from%2520Cockburn.pdf&ei=cEjDUJbyFsPj4QS4kYH4Ag&usg=AFQjCNGsZkpSqx_WTO7E-lm_bGSiv-L5Gg&sig2=bdpslbjKCzqdiIVEF262kA http://www.google.dk/url?sa=t&source=web&cd=1&ve...

biggs 14y ago

Are there any applications (mobile, web or whatever) whose sole purpose is to help a programmer capture the program that is in his/her head? The first thing that comes to mind is UML based applications like Rational Rose. But those seem to have such high barriers of entry and are more geared towards communicating the program to other developers or different stakeholders.

alcuadrado 14y ago

This is totally misleading, and may make people feel they are not good at programming. To quote one of the masters of CS: The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. Dijkstra (1972) The Humble Programmer (EWD340)

stcredzero 14y ago

Holding a large program in your head is like holding a city in your head. You can't entirely do it. What you can do is to know broad outlines and principles, so you can navigate to the relevant points and negotiate difficult parts. When you see the details at the relevant places, then you can deal with them. It's like being a cab driver. You don't memorize every cobblestone and pothole, but you know how to get where you need to go you can deal with them as you're driving.

JoeAltmaier 14y ago
You can visit the neighborhoods often enough that they are quickly familiar when you happen upon them again. That's called a domain expert. In fact, London cab drivers DO hold the city in their head. They are required to, before they get their license.
- stcredzero 14y ago
  Yes, I was thinking about what I read about London cabbies. However, they don't necessarily have recall of every pothole and cobblestone. They remember enough of a map so they can get to where they need to be, and deal with what's there on the way.

slant 14y ago

I find it interesting to read this again after a few years only to realize that Paul is in direct contradiction of those who would have us take a break every 25 minutes with his second point. It's kinda refreshing to hear this point of view again. I worked 5 solid hours last night, starting that particular stretch around 7pm and got around 3-4 normal work days worth of work done.

zipdog 14y ago
Yesterday a friend explained the physiological reasons behind 25 minute breaks: basically the muscles (including eye muscles) go into a different state of relaxed-tension and its generally not good for them to be in that state while the body is sitting-looking. There's also the issue of the effort required to concentrate on a task, which gives diminishing returns as you extend it beyond ~25 minutes without break. However a mental flow state (what you seem to describe) requires little to no concentration effort and so can yield great returns over the time spent. The tradeoff is that the body is in a less-than-desirable muscular situation for a prolonged time - but I'm guessing the damage there is not so significant if 8 hour flow sessions are not a daily habit. tl;dr: the 25 minute break thing is probably a good general guide, but shouldn't stop you pulling an 8 hour session if you are absorbed and productive

njx 14y ago

I do it. I build mockups in my mind, run through clicks and interactions and finally the code flows.

w_t_payne 14y ago

Perhaps the key to a productive software industry is - paradoxically - to de-industrialize. Model the organization and communications patterns on a guild of independent workshops, each workshop comprising one artisan developer with one or two apprentice developers, with each workshop supplying hyper-specialized services based around a library of existing, re-deployable functionality.

8ig8 14y ago

I just came across this article in a HN post last week that was discussing a similar theme. I think it does a great job explaining the challenges of beings programmer... http://alexthunder.livejournal.com/309815.html http://alexthunder.livejournal.com/309815.html

irishcoffee 14y ago
This is a fantastic summary, and I thank you for sharing.