how LISP changed my professional life
Part of this meme:
LISP
The most valuable part of my education as a technical writer was my student job with the Common LISP project. It was also either the first- or second-most important part of my education as a software developer. Yes yes, the classroom stuff was important and the software-engineering project course was essential for putting the pieces together, but this was the real world and the real world is far less tidy than the classroom.
I was brought on to help write the documentation for this then-in-development language. (Other varieties of LISP existed; this was an attempt to unify them.) But unlike all my previous tech-writing work, this was for a thing that did not fully exist yet, and I was part of the ongoing design process. I was there in the (virtual) room with the lead designers, Guy Steele, Dave Moon and dozens of others big and small, and if my contributions had merit it didn't matter that I was an undergraduate with no real experience. On the ARPAnet nobody knows you're a dog undergrad. Mind, being an undergraduate with no real experience, I didn't necessarily have a lot of design ideas to contribute, but even then I was pretty good at catching inconsistencies and asking key questions. I learned to write software-interface documentation there, but even more importantly I learned to be part of a real software-development process, to ask questions even if they might seem "stupid", to argue for technical positions and support those arguments, and to be a full member of a team.
When I graduated and met more of the real world I would learn that it usually doesn't work like this. In a lot of places, technical writers are not part of the development process (and may not even be in the development department) and the attitude is that they can come in after the developers are done creating the product and just write down how it works. Phooey on that; this important early experience taught me that it doesn't have to be that way, and I have held firm on this in every place I've ever worked. If I don't have a seat at the table during the design and development of the product, I'm not interested. If I hadn't had this early lesson to show me what is possible, I might well have fled the field.
It is also because of the Common LISP project that I went into programmer documentation (and expanded from there). Frankly, a lot of what's commonly assigned to technical writers bores the heck out of me, but building software development kits and making complex products accessible is exciting and nourishes my inner geek. When I went to college I hadn't even heard of technical writing (I went there to do computer science), but I came out as a technically-proficient writer who knows the good that is possible. I have Common LISP to thank for that.
LISP
The most valuable part of my education as a technical writer was my student job with the Common LISP project. It was also either the first- or second-most important part of my education as a software developer. Yes yes, the classroom stuff was important and the software-engineering project course was essential for putting the pieces together, but this was the real world and the real world is far less tidy than the classroom.
I was brought on to help write the documentation for this then-in-development language. (Other varieties of LISP existed; this was an attempt to unify them.) But unlike all my previous tech-writing work, this was for a thing that did not fully exist yet, and I was part of the ongoing design process. I was there in the (virtual) room with the lead designers, Guy Steele, Dave Moon and dozens of others big and small, and if my contributions had merit it didn't matter that I was an undergraduate with no real experience. On the ARPAnet nobody knows you're a dog undergrad. Mind, being an undergraduate with no real experience, I didn't necessarily have a lot of design ideas to contribute, but even then I was pretty good at catching inconsistencies and asking key questions. I learned to write software-interface documentation there, but even more importantly I learned to be part of a real software-development process, to ask questions even if they might seem "stupid", to argue for technical positions and support those arguments, and to be a full member of a team.
When I graduated and met more of the real world I would learn that it usually doesn't work like this. In a lot of places, technical writers are not part of the development process (and may not even be in the development department) and the attitude is that they can come in after the developers are done creating the product and just write down how it works. Phooey on that; this important early experience taught me that it doesn't have to be that way, and I have held firm on this in every place I've ever worked. If I don't have a seat at the table during the design and development of the product, I'm not interested. If I hadn't had this early lesson to show me what is possible, I might well have fled the field.
It is also because of the Common LISP project that I went into programmer documentation (and expanded from there). Frankly, a lot of what's commonly assigned to technical writers bores the heck out of me, but building software development kits and making complex products accessible is exciting and nourishes my inner geek. When I went to college I hadn't even heard of technical writing (I went there to do computer science), but I came out as a technically-proficient writer who knows the good that is possible. I have Common LISP to thank for that.