When I started my first job as a programmer, I was surprised how much time my colleagues spent at their computers. Of course a computer programmer needs to spend a fair amount of time sitting at a computer, but why did people spend nearly 100% of their time in front of a monitor? This seemed strange to me since I hadn’t worked this way before. I had always alternated thinking away from a computer and sitting down at a computer.
I was even more puzzled when the network went down, which it often did. Half of us worked on Windows PCs and half worked on Unix workstations. When the network was down, the PC folks kept working because they had self-contained local work environments.
But the Unix folks would stand in the halls until the network came back up or go home if it looked like the network wasn’t going to come up soon. They had computers on their desks, but these were primarily used as terminals to connect to servers. So without a network, the Unix folks essentially had no computers. Everyone agreed that meant they couldn’t get any work done. That seemed bizarre to me.
At that time, I knew how to program, but I knew almost nothing about professional software development. Many of my ideas were naive. But looking back, I think I was right about one thing: programmers need to stand up and think more. Too often, that’s the last thing we do.
Related links:
Good post. I still remember Bjarni Jonsson’s retirement party at the Vanderbilt Math Dept. He gave a good short speech in which one of the themes was, and this is a direct quote, “We spend too much time trying to solve problems and not enough time trying to understand them.”
Sure. But the boss man don’t think I am working unless I am looking at the monitor. You know what I’m saying?
If I’m thinking about what I’m doing shortly before doing it, it must mean I’m daydreaming when I should be working.
Rich Hickey (author of Clojure language) gave a talk about this, called Hammock-driven development. I also try to think about design of my tasks without computer, only using paper and pen – this is old habit from early days, where computers were not always accessible. Usually I get better solutions if I’m thinking without computer, comparing with people who are trying to code without thinking
Well the analysis you are making is interesting because the culture shape the limits of what can happen.
Your costumes shape (by design (of the experience)) what details you will pay attention to.
So, for me makes a lot of sense that being forced to spend more time away the computer kind of helped to program more thoughtfully.
But the problem isn’t in staying in front of the computer or not. The fundamental problem is worrying (and spending time or working) on the irrelevant details too soon and overlooking the whole.
In design you’ll see found this as the Cathedral Effect.
The thing is that you become biased about the things you pay attention to in relation to your view (perspective, worm’s view vs. birds view). High ceilings aid creative thinking and low ceilings induce detailed thinking.
This is testable.
The tool (and the room or place where it is) inspires the artist (or expert).
So I’m far from being surprised if the unix guys that where motivated to do computer stuff but where inspired to program better while walking to home (or to get the bus).
They compensated the frustration of downtime with self-motivation while thinking outdoors for a while creating a more favorable context for insights
I find this fascinating simply due to my own background. I learned to program computers without a computer — not being able to afford one in the 1980s. I was able to arrange for some limited time (e.g. one hour/day) on a university timeshare system. So in an ordinary paper notebook with a pencil, I would I would write out page after page of BASIC code and later in the evening enter it into the computer and try it out. I am convinced it shaped my way of thinking, and coding as I do more “development” during my commute or walking around the office.
I have similar experience and I agree with many points you made. Personally I do not like shoddy work but when my boss would hang albatross around my neck, I just do the work for sake of doing it.
I was working for a firm engaged in algorithm trading and all the members were new. The firm itself was new. Although we had a great team of programmers and team lead, the manager who was CTO of the company had no experience handling an engineering team. He used to ask for too many modifications and simultaneously work on too many new features and applications (it was a distributed application), that we had absolutely no time thinking about the problem. We used to complete the work. It went for months before shoddy work took over.
Many of the guys in the team including me left the company.
The point I am trying to make resonates the concerns of Maintnance Man. If your boss do not understand this, you are helpless.
I find myself using the computer for more and more things I used to do by hand. I use symbolic math packages to simplify expressions I would have worked out on paper before. I am more confident of getting the right answer, and I can test the result numerically as well. Even when I want to derive something “by hand,” these days I am likely to use TeX to do it. I find that neatness counts, and that I am more likely to put in more detailed steps. Further, it’s nice to have notes online that I can refer to later, or work into a more formal document.
I agree with the advantages of writing things up in TeX. More of my thought on that here here. In short, I find LaTeX a great way to analyze and preserve notes, but not a good way to create ideas.
I work in an environment with a mix of software, hardware, mechanical and other engineers. Distributed version control systems mean that most of the (Linux-using) software people can continue to work when the network is down — but the mechanical and systems people (and their Windows-based CAD tools) come to a screeching halt because they cannot talk to the servers that hold their models. I don’t know that the difference means much except that you can’t tell who depends on the network to get things done based on their operating system.
More to your main point, I do wish that our software developers would spend more time on analysis and understanding, and less time throwing code against the wall to see what sticks…
Michael P: I didn’t mean to imply that network-dependence depended on operating systems, at least not now. That’s just how our office worked.
Now everyone is hopelessly dependent on the internet no matter what operating system they use. :) It bothers me that so few applications work well when disconnected, even applications that have no apparent need for a network connection.
I’m responsible for the user interfaces on our product, which runs a large piece of industrial equipment. I realized a while ago, with substantial dismay, that I did not know how to operate the equipment. How could I possibly design and build a valid UI without that basic piece of knowledge? Since then I’m trying to get more time in front of the machine.
I think that pair-programming is often effective at forcing programmers to think, since 50% of the pair is not typing at all times.
Not a panacea, of course . . .
Gary: I’ve had a similar experience. A few years ago I was preparing to give a short course on clinical trial software my group had developed. I had used the software mostly through lower-level interfaces not surfaced in the UI. When I started preparing my talks, I clearly saw the software from a new user’s perspective for the first time. I requested several changes to the software to match my expectations as a user.
Gee…
Am I the only one left who used to write code on a grid form in pencil to be sent to the keypunch department? When you could expect two, maybe three turn arounds a day you tend to spend more time planning and desk checking.
Jim: I’ve written code on paper, but I just missed punch cards.
Donald Knuth still works on paper first. From an interview:
John
Good to know there are still some of us old timers around! Honestly, reminiscing about coding with a pencil is on a par with describing your walk to school through the snow (uphill of course). When the text editors came along I was happy to leave punch cards in the rear view mirror. I never expected to see the day when your editor would practically write the code for you.
Still, I think it was good training. I learned the habit of trying to get it right the first time.
These kids today and their computers…
Jim,
I started in that era too, writing Cobol on cosing sheets. We had hand card punches for minor amendments and even used to rub the chads back in with a pencil when we made a mistake (until the vacuum card reader came along). I also remember at college loading the Algol compiler on paper tape and rewinding it by hand.
Like you, I wouldn’t want to go back to those days, programmimg is more fun now – but 24 hour turnround and 128k of memory did concentrate the mind.
Tony
Thanks for that. It’s my birthday this month and I guess I’m feeling old.
Paper tapes. I remember generating HP’s RTE operating system by feeding boxes of paper tapes through a teletype. Not nostalgically either. And COBOL! I used to pretend I didn’t know it and mostly that worked.
I surely wouldn’t trade C# for the ‘good old days’ but we did have 64K – and we liked it!
You are right my friend, sometimes i have better ideas, sit down in the church, or Stand up in the bus, watching movies, than 24/7 face to face to the monitor, i have people that says that i waste to much time, but the deal is that when i come back to the PC, the problem is solved as fast as i can write the code.
This have been truth since I’m in college.
I learned to program on punch cards, and had to wait 10 minutes for my jobs to run and be printed (bad old days). For years, I felt that having to program using pencil and paper was better than sitting behind a terminal. I no longer believe this.
Being able to correct typos as you enter your code is an obvious win (not available with the model 026 keypunch). But more than that, being able to quickly express your thoughts and then look at the results produces better code faster. I still have to draw diagrams on a whiteboard, but when you do this with a team, you also need to copy down the result (on a computer) just so everybody has it. If there was a decent gesture-based diagramming tool you could use in front of a group, it would be better still, but we aren’t there yet.
This productivity comes at a price. If the net goes down you can’t print. If your workstation goes down, your highly productive tools are unavailable and you feel as if you’re swimming in molasses. It’s so SLOW to write code on paper, and so hard to make changes in a readable way. You can’t do maintenance at all because you can neither see nor remember 100,000 lines of existing code. You can chat and wave your hands in the air, but what have you got at the end, other than your rather fallible memory.
Fluency with tools takes time. You’ll grow into it.
That’s why I like to take my notepad & clipboard and head to my favorite watering hole to do some of my best work. :-)
Still working with papers. design, coding and of course I don’t forget to plug myself out to think.
Couldn’t agree more. Perhaps this is a microcomputer era thing, couldn’t be done when you didn’t have a monitor and had to punch cards and wait in line for their processing. And probably it has to do whit this accelerated fast-food times we live in.
Years ago I realized that I was making bad software even when I was not creating but only doing maintenance in code written by me or others.
I wasn’t analyzing the task at hand properly, wasn’t thinking on the future implications of the kind of code being written, was making things that would have to be patched over and over and finally, reinventing the wheel in a daily basis.
That’s when I stopped to imediately start typing after a problem was post. Paper and pen it’s essential for me now and also getting away from the computer to do a complete different thing, like washing the dishes or taking a shower ( always making a strong effort to stop thinking about code and stuff ).
The reason for this is that typically a programmer is putting together something using a dozens of different APIs. They need to be a at a computer to reference documentation related to these APIs because there’s no way you can keep all of that in your head.
In the old days we also had something called printed documentation. Something I really miss. No search function but the index worked pretty well. You could curl up in a chair and study one. I’m talking about reference manuals – not programming texts. They were portable and could be carried down to the watering hole too!
For me, poetry in a functional language (esp. Haskell) in lieu of prose in others finally frees me from the keyboard. I think I’m more “productive” with a decent clipboard and pen than in front of the monitor, but not always. But the combination of deep thought and concise language is key to freedom.
I think that the Windows guys were spending a lot of time reading documentation from local sources. For me, it seems like everything from Win32 to DotNet has been incredibly dependent on the library documentation. It is good to reuse software, but the sheer detail of the APIs make one wonder if it is always worth it.
I noticed that most people working with computers (programmers, designers, etc.) one day start to feel a kind of ‘computer dependence disease’ (I felt :) ). It is when you cannot imagine what you will do without keyboard and monitor. You even cannot imagine that some jobs require other set of tools (like paper, pencil, chair and cup of coffee).
Programming companies and teams need to practice a computerless therapy! I did it organizing two work places for each programmer – one with computer, and another as a table with paper, stationary, etc. Two tables, two chairs, different corners of room. We also did some speaking meetings with blackbord or flip chart.
Force your people (and yourself) to think, speak and write by hands out of monitor. It is works!
John sounds like a true techi, actually most of us do programming for our JOB. There is difference between solution providers and a just programmer
I think maybe many of them love the computer, after all, nowadays people can make friends , go shopping and enjoy themselves on the website. During the working time, I think bosses don’t like staffs walking away, they want to control their staffs, so staffs have no choice but sit down in front of the monitor.
I agree it’s good to get away from the computer sometimes when trying to solve hard problems. Many times I’ve struggled with a problem, and then realized the solution when I took a break to go to the bathroom.
I sometimes realize solutions to hard problems at work after I get home. Sitting at a computer can lock you into a mindset that’s hard to change even when it’s unproductive. A change of environment can change your point of view.
John-
I’ve often wondered what those of us who have never had to program anything on a punch card have lost. When I’m working on a problem, I can spend hours fiddling with some simple Mathematica code hoping to get an output that looks plausible instead of ever sitting down (or standing up) to think about what I’m actually trying to accomplish.
I’ve rarely, if ever, been in a situation where I had any delay between decided what tool I’m going to use to solve a problem and actually using the tool. I suspect that if I had to sign up for “Mathematica time” (perhaps at 3 AM on a Saturday when the professors had gone home), I would go about problem solving in an entirely different manner.
It’s a strange world we live in.
I think it’s probably a matter of personal style as much as upbringing. My mom wrote her dissertation in education on approaches to writing, in part contrasting those who wrote outlines and plotted everything out versus those who just started writing linearly. For both approaches, there were lots of examples among pros and amateurs.
I started out on punch cards (actually, mark-sense cards and a teletype before that and a TRS-80 at the local Radio Shack at about the same time). I even made good money as an undergrad as a keypunch operator (better pay than being a math TA!).
I tend to be a planner for both coding and writing. “Measure twice, cut once” as the (woodworking) carpenters say. My wife and the guy I work with at LingPipe both are as old and wizened as me, but both like to sit down and start working without a lot of advance planning.
It can be overdone either way. I’m not one of those architecture astronauts who thinks you need a huge process to lay out a simple API.
The best programmers spend 98% of the day thinking how to solve a problem and 2% coding.
Absolutely correct. I write code in my IDE, on scraps of paper and notebooks. Sometimes I like to sit in the living room (with family and television and all) and focus on one of my many programming/reference manuals or the latest specs on whatever language I’m dabbling in.
Not lately, but I used to fall asleep in a myriad of books and notepads when I first started programming. I seem to do my best ‘away’ from the computer and then I return with my ideas. This isn’t always the case and there were times I sat staring at the monitor like it was a magical mirror waiting for it to give me the answer.
Great topic and post, thanks.
Long ago but not too far away, I was working on a take-home math final — all theory, and we had a long time to work on it.
I finally went to sleep, and in a dream Isaac Newton showed me the solar system, which became the domain of an analytic function, which went through some iterations. When I woke up I realized that it was the proof by construction that I needed for the problem I was solving.
I think a lot happens when we are not actively thinking about or working on a problem. Some of this happens to me especially when I am not at the keyboard.
There were no screens back on the IBM 405. There was keypunch card decks, and plug boards. If the program had a bug, it was due to a broken wire. I’ve been through al the changes since then. There was a time when I wrote my code on a chalkboard and walked through it until it worked correctly. Another time, I typed my code into the buffer long before it got on my screen, the system was that slow, aka not optimized for student use.
More recently, it took me hours to get in the frame of mind to code, but once in that frame of mind, I didn’t want to go home. Getting into that frame of mind was a problem, because I coded so irregularly. I had to go back and figure out where I stopped.
Agile gets you into that keep throwing it against the wall habit.
All of this will change and keep on changing.