One path to lots of money from writing is to fish, fight depression, and drink excessively on your favorite island in the stream, but there are move liver-friendly methods that don't involve long hours gutting helpless blue marlin and hating yourself. This week I accepted a generous employment offer. Here's something that helped. Agile Methodology is canon in information technology. Say bad things about Agile, you won't win friends or influence anyone, and I don't argue with the common-sense portions of Agile. I said as much in my interview, and then said there are also serious problems with Agile. The worst is one of the four main values in Agile (agilemanifesto.org). Working software is more important that comprehensive documentation. Telling that to a developer is functionally the same as telling him or her to forget documentation. Whether or not technical writing is any fun or not, documentation developed in parallel with software makes better software. Documentation endures, and as staff changes or new customers start using an application the best corporate memory is good old documentation, in the forms of inline comments, auto-generated documents, and separate prose. When I said I liked to write, the room brightened. I followed that up with the fact that every large programming project I've done started with a word processor, not a flowchart or a compiler. My experience may not be universal, but I think in this millennial world of 140 character tweeters, there is an understated demand for those loquacious at the keyboard. I am not a professional writer. I landed a nice role at a big company because I am a writer. Archimedes said, "Give me a long enough lever and a fulcrum on which to place it, and I shall move the world." I'm one up on the old fellow. I don't need a huge lever. I have a pen. It's amazing what those things can do.
I dunno, I wouldn't put as much emphasis on the value of writing for software roles as you're putting on it. It's a valuable plus definitely, and especially as an addition to a team that probably doesn't have those skills, but there are a lot of other skills that come in handy too. Design, business, marketing, math, science, physical engineering; things like that add to your talent stack and they are very helpful. How much they help will vary on the industry, specifics of the role, etc. (I'm about to get in the weeds of how software teams should work. Feel free to skip this part, unless you're interested in this stuff) Whether documentation is valuable depends on how fast your team moves, balanced against the complexity of the software and expected maintainence burden. Extensive documentation can easily become outdated, and is often overlooked in favor of asking someone who knows about the system. My advise would be to write clean, readable code. Use a formatter and linter to keep consistent standards. Add inline comments to anything ambiguous, and ask that they be left in code reviews if they aren't there. Then create basic high-level architectural documentation that outlines the basic structure of the system. This will work well for most teams that want to get things done and are not dealing with a few particular special circumstances. If you work in a regulated industry (such as aerospace) or an industry that operates on slower schedules with an expectation of more maintainability, then there may be value in investing in much more docs than I would normally recommend. When you start a software project in the word processor, what do you usually write? I was taught to follow a process like this in Computer Science class, but I found it rather old fashioned and clunky. I might start a project with a series of technical proposals, depending on the nature of the team, though I would not plan out APIs inside a word doc for instance. (Resurfacing back from software land) Technical writing is definitely a thing, and writing is a plus for any role in business really. I'd say it's just a plus though and it's important not to lose sight of the main skill set. Each profession has its own best practices though of the professions I have a working knowledge in (Writing, Design, Engineering, Entrepreneurship), the good practices are at least 70% the same.
I am a professional creative writer and my liver is just fine. Sure, it's hard, but I rather give creative writing all I've got than be writing something that wasn't a step toward reaching my goals. Maybe you just want to write and any kind of writing is fine for you. But people do and can be professional writers. I don't know if you're calling yourself a writer when it comes to your new job. And it's fine if that's how you see it. However, not everyone has to go down the path of seeking out other professions where non creative writing is what it takes to become a "writer." Sure, it's hard to break into the industry, but it's not impossible. Good writing gets noticed. And if you're not getting noticed, it means you have to get better. Or you can take a job doing something else, but I hope the writing you're doing at this job isn't the only thing you're writing if you actually want to be a writer. Congratulations on the new job, anyway. I hope you'll be happy there because you do sound excited about it.
Interesting comments, and I appreciate your views. I write in a variety of settings. Fiction, essays, and my projects get respect for transparency. Doxygen or Javadoc is very nice, and inline comments are as important as the code. Out of date documentation can be useless - but might be better than no documentation. Probably the most intense project I ever did ran about 200 pages of 8 bit assembly language. Inline and automatically generated documentation had the lowest levels covered. The initial writing I did with a word processor was mostly a user manual. I write more precise code when I have a precision target. Targets shift, but I still do my best work with a defined target. To each his own. Writing may not be a universal skill in the modern world. I’m probably just in a phase. I’ll grow out of it.
