Do programmers write reports/essays?
Hello. My writing skills in school are lacking, and I was wondering whether they are important for programmers (Writing reports on how his/her code works, etc)
I have hired good communicators who are adequate programmers, ahead of good programmers who are awful communicators. We need people who are good at both; it's easier to teach programming skills on the job than it is to teach good communication skills.
There is an enormous amount more to being a good software engineer than just churning out code; the ability to fluidly and fluently communicate with other people is a fundamental part of it.
It's not so much specifically writing reports or essays, as the fact that almost everything we do involves communicating with others. Requirements, testing, design, negotiating, all of it; so much of it involves the written word.
Being a good programmer makes you a good programmer; to be more than that (such as a full-spectrum software engineer) requires a lot more and competency with the written word is a large part of it. A well-written specification is a thing of joy; a badly scrawled set of poorly explained requirements is a disaster in the making. A well-crafted bug report leads to a quick solution; an unclear bug report that reads like someone just spoke out loud and wrote down the words that came out of their mouth is enormously frustrating and time wasting.
Various technical books have come and gone across my desk over the years, but there's always been a style guide somewhere in the pile - sometimes Strunk and White, sometimes the Economist style guide, probably others too. Software engineering is communicating; sometimes with the computer, sometimes with other engineers, sometimes with customers, sometimes with sales, and more besides.
There is a clear difference between being a good writer in the way that Tolstoy or Murakami is a good writer, and being competent at explaining technical matters effectively. The second can be learned through simple practice and deliberate improvement.
There is an enormous amount more to being a good software engineer than just churning out code; the ability to fluidly and fluently communicate with other people is a fundamental part of it.
It's not so much specifically writing reports or essays, as the fact that almost everything we do involves communicating with others. Requirements, testing, design, negotiating, all of it; so much of it involves the written word.
Being a good programmer makes you a good programmer; to be more than that (such as a full-spectrum software engineer) requires a lot more and competency with the written word is a large part of it. A well-written specification is a thing of joy; a badly scrawled set of poorly explained requirements is a disaster in the making. A well-crafted bug report leads to a quick solution; an unclear bug report that reads like someone just spoke out loud and wrote down the words that came out of their mouth is enormously frustrating and time wasting.
Various technical books have come and gone across my desk over the years, but there's always been a style guide somewhere in the pile - sometimes Strunk and White, sometimes the Economist style guide, probably others too. Software engineering is communicating; sometimes with the computer, sometimes with other engineers, sometimes with customers, sometimes with sales, and more besides.
There is a clear difference between being a good writer in the way that Tolstoy or Murakami is a good writer, and being competent at explaining technical matters effectively. The second can be learned through simple practice and deliberate improvement.
Last edited on
Topic archived. No new replies allowed.