Thoroughly agreed. As a developer who spent a lot of time studying humanities, arts and other disciplines requiring constant writing for grant submissions, essays, etc. a lot of skills required to be a good developer become invaluable for a dissertation and the other way around.
> A core skill in both disciplines is an ability to think clearly. The best software engineers are great writers because their prose is as logical and elegant as their code.
Personally, I found that combing through my text again and again and again to cut down on unnecessary words, combining similar ideas ideas and clarifying points made a huge difference, and was very much akin to optimizing software. It was generally something other students didn't really bother to do and their writing greatly suffered from it.
I recently worked as an expert witness and had to write a report, I haven't written anything since University ~15 years ago. Writing a technically accurate report about source code for a non-technical audience was amazingly difficult. It was fun, but stressful. Each sentence has to be able to withstand a cross examination, sometimes it took hours to write a single sentence.
I'd do it again, and I recommend anybody that gets the change to do it as well.
> Personally, I found that combing through my text again and again and again to cut down on unnecessary words, combining similar ideas ideas and clarifying points made a huge difference, and was very much akin to optimizing software.
I learned these optimization techniques later in my grad school studies (a very critical adviser helped), never learning how to really write as a CS undergrad. Now I am the go-to guy for paper editing, and I find it frustrating that I can't seem to teach this to those I help write papers.
I find myself uncertain about the thesis. Code that is clear and expressive to a human should not be assumed to also be efficient and optimal for a computer.
Code is designed to solve problems. If someone can't read your code, they are going to have a hard time using it to solve their problems. If you don't document edge cases, modes of failure, intent and methodology... then it is worse code than it could be. Somebody won't be able to use it because they won't be able to tell if it solves their problem.
A few weeks ago I read a quote about someone saying that good code should be 'self-documenting' and that it should be obvious what it does. This is a red herring -- it assumes you wrote code that works perfectly. If there is a bug in your 'self-documenting' code, then how is someone supposed to know if it is wrong or not?
True enough - but code that humans can't read is far more difficult to debug, to profile, and to optimize. Efficiency can be improved after the code is working, but improving readability on a prematurely-optimized codebase frequently involves `rm -rf`.
I didn't see what you are seeing in the thesis. There was nothing that said that the sole end goal of programming is to be expressive to humans (whether those humans be yourself, other coders or end users).
As for audience, when coding you can consider your audience to be both humans that follow you, as well as the machine it is running on.
One of the ideas mentioned is that code that's readily understood by humans is code that will be efficient for computers. I'm not sure I agree with this.
I was always an "English kid", came close to failing my math subjects in middle school and finally in high school, I did fail Algebra I, and had to re-take it the next year. Meanwhile, I was in advanced programming courses and on my way to take an AP Computer Science course in the last semester of my sophomore year. Looking back, that experience taught me about how important modeling is to pedagogy. The fact is, my Algebra I teacher couldn't model the problem for me. He never explained anything, just expected us to memorize everything. We were never given real, tangible examples (contrived word problems don't count and never did!)...all we did was take stupid tests. My high school math experience was like a crash course in everything that's wrong with STEM education in America, and why we need to alter that if we're going to depend more on STEM in the real world.
In my opinion, programming has always been a form of writing. Just like songwriting is a form of writing. It's simply a different medium, and therefore you get a different result.
I might be looking at it from a different kind of lens though.
Somewhat related is a recently published book by Angus Croll called If Hemingway Wrote Javascript[0]. It's not so much about Javascript as it is about the writing styles of great authors and the expressiveness inherent in writing code.
> Looking back, that experience taught me about how important modeling is to pedagogy.
Very good point!
This is the strongest "pitch" for why one should learn math: the modelling superpowers one will acquire. Every function f(x) is a type of model (e.g. mx+b, x^2, e^x, ln(x), cos(x), |x|, etc.), and understanding the function f(x) will allow you to model any phenomenon that exhibits f(x)-like behaviour.
[note: I'm working on the web copy for a math book and trying to decide what to put above the fold to make the average Internet reader interested in math. So far the shortlist of pitches are (1) learn math easily because the book is short and written in a chill tone, (2) destroy your calculus and mechanics exams (for students), (3) get rid of math phobia (for English kids), and (4) gain modelling superpowers. So far I like (4) the best. What do y'all think? Any feedback would be much appreciated. ]
"gain modelling superpowers" makes no sense to someone who doesn't already understand what modelling is and how is can be used. It is also a comical idea to try to market a book toward students these days - getting even a high school student to read anything longer than a few sentences in one sitting is a miracle.
> a comical idea to try to market a book toward students these days
I agree with you generally, but if you compare with the current math textbooks (that students are usually forced to buy) you will concede there is a lot of room for improvement on the textbook side.
Also, while I think technology might be cool to play with, nothing beats the book as a medium for the transmission of information.
I did very well at English at school, but failed hard at maths whilst freelancing from home after teaching myself PHP.
I really wish I'd engaged (and was taught) maths in the same way as I did with code - I remember feeling quite annoyed at the way I was being taught maths which was basically "when you see a question asked in this way, you answer it by following these steps". I think if I'd been taught maths through experimentation and having "projects" to solve in the same way I learned to code, I would've been quite a good maths student.
I always felt like school-level English classes were very hazy, muddy environments where you didn't need to have clear thinking and the structures (the English language mainly) didn't strictly follow any internal logic, opposite math. Peers got good marks for presenting half-baked ideas in inarticulate, thesaurus-abused essays, as long as they made sure to repeat their limp argument, cut up into a specified number of points, in the extremely redundant structure imposed by the curriculum (say what you're going to say, say it, then say what you said, with different synonyms each time) and use different joining-words or whatever term they used for obnoxiously putting "also" "further" etc. at the start of every new paragraph. Intellectual laziness was rewarded by the system, purposefully or not.
Those classes probably turned off a sad number of would-be good writers from learning how to write creatively, efficiently, or even reasonably. I had exactly one English teacher who was reasonable and only taught to these abominable standards as required by the state but let real writing be rewarded in other assignments; he understood the reality of the language and that the point of your writing should be moreso effectively articulating ideas, effecting desired emotional responses, or provoking thoughts rather than some nonsense a committee at the Department of Education decided is proper and that legions of English teachers across the country take to heart as dogma and revel in the sadism of. Otherwise, throughout the years it was splitting hairs over prescriptivist grammatical minutiae, the aforementioned ridiculous essay structure, memorizing obsolete Shakespearen-era "vocabulary words" that no writer writing for a living audience would even consider using, and going on about how any grammatical structure or word that appeared after 1900 is objectively wrong.
I could have put much less effort into them than I did and still gotten As but I preferred to use them as an exercise in trying to work good writing around the myriad deeply-rooted problems in how I was forced to present it. That's the only bonus point I can give to it as a learning environment.
English classes in college have just been the same disappointment with a different mask on for the most part, except for exposure to real research methods, but still lag behind the real world in forcing you to use non-internet sources.
I also disliked the emphasis on literary analysis. It so often seemed like contrived flimflammery crossed with psychoanalytic mumbo-jumbo. If tvtropes (or allthetropes) had existed back then, I think I would have performed much better on my English homework. After all, those sites do include the Jungian archetypes and the basic plots as a subset.
As it is, my high school English classes drove me far away from anything even remotely similar until a lifetime of reading fiction, a shameful amount of blathering on Internet message boards, and the exhortations of the "National Novel-Writing Month (NaNoWriMo)" organization convinced me to try to write a novel in November of 2012. Two years later, I have written 500 kb, with maybe 130 kb left to go before I snap it off and start the next one. Then there's also the matter of the default HTML stylesheet, continuity notes and timelines, the character, vehicle, location, and artifact indices, working hyperlinks, and testing the release version on all available e-reader programs and devices.
As for my old English teachers, I bite my thumb at them, like Sampson. I give them the fig, like Vanni Fucci. And just as golf is a good walk, spoiled, English class is a good read, ruined. Even with those ancient cultural references rattling around my bonebox, I find that an increasingly large fraction of my memes are drawn from television, film, music, video games, and popular web sites, and a vanishingly small portion from the old literary canon.
That's how I know that the Belmonts love Devo. If you understand why, you probably won't need to thank an English teacher.
All I really ever needed was a pile of books that I enjoyed reading and a copy of Strunk and White (minus the part about always putting sentence punctuation inside the quotes, because that's just madness). What I got was about 10 years of pedagogical torture that discouraged me from trying something that turned out to be a fun hobby.
I completely agree with this. I've started blogging for my work on some of the things that I'm actually writing code for.
I've actually found that it helps me think about more of the big picture stuff. In writing my first post about one of our APIs [1] I actually realized that there was a small omission in how we designed it.
There are times I wish I could go back to my younger self and explain exactly this. Unfortunately it took me almost a decade as a software engineer before I realized there was a career barrier without being able to communicate effectively when writing or presenting.
It's possible to stay as an average engineer for a long time, but if you want to try being an Architect, then at least 50% of your time is spent writing or public speaking. If you want to be an engineering manager, that's over 90%.
Fortunately a company I used to work for believed pretty strongly in cultivating these "soft skills", so they incentivized things like Tech Talks, and covered the cost of courses like Dale Carnegie.
The TechTalks had a few purposes. First, it was to spread knowledge within the company about what other groups were working on and how they were doing it. Second, it was for recruiting new developers. (If the talk went well internally, then we were often asked to do it again for local developer groups or meetups at area colleges.) Third, it was part of the career development they tried to do - trying to create good Architects that knew the business and the problems that needed to be solved.
The talks were incentivized as part of the bonus structure. If the company did well, and you completed your goals, then you could get up to X% of your salary as a bonus. (Also, they usually included free lunch)
The technology and the people at that company were really great to work with - I probably got more experience in one year there than five years at any other company. Unfortunately it was in the advertising business, so many of the business practices were slimy and cutthroat. (It seemed like every month we had a crisis where either Google, Microsoft, or Apple didn't like what we were doing and wanted to shut it down.)
Highly agree with this - I am baffled why the humanities aren't taught this way in US high schools. Writing always seemed difficult to me then, but upon taking my first college class which had lots of essay writing, it dawned on me that making a persuasive argument was the most important part of an essay. This has much in common with the critical thinking touted in the hard sciences & mathematics. If English was taught this way in K-12 education, instead of enforcing arbitrary rules such as page length & word count, I would have done immensely better.
I got the important takeaway from that experience, but many people do not, and it is a shame.
Why stop at essays or technical articles? As an engineer, I've always been fascinated by the structure and inner mechanics of stories - what makes them work.
As a hobby I've done a lot of reading around this; I've written three feature-length screenplays, and a novel you can find in Amazon[1], using very structure-centric approaches (as a result, my characters tend to be too flat).
Take a look at The Snowflake Method[2], unsurprisingly designed by a novelist who is also a theoretical physicist. Even with The Hero's Journey, there's a surprising amount of well-understood structure behind every story.
The pistol on your novel's cover is a CZ-75. It's not an unknown gun by any means, but it's relatively uncommon in real life; sushi to the hamburger that is a Glock or a Beretta. Despite this, it's a common choice for infographics where just "a gun" is needed, and I can't for the life of me figure out why.
I'm curious - do you know why that particular pistol was chosen for your cover?
Interesting, never thought of figuring out the model!
The cover was made by a freelancer I found on 99designs.com (I'm really happy about that experience, BTW - and I have nothing to do with them, I just liked the service). The pistol looks good and the image was royalty-free, which is probably why the freelancer chose it.
But in retrospect you're right, I should have checked. The only pistol specifically mentioned in the novel is a "H&K" (not even the model), but there are many other anonymous ones. This CZ-75 could be one of these :)
I've just completed a screen-writing course, and wrote a feature-length screenplay as part of that process, and was struck by how much like technical writing it was. A screenplay is not a story the way a novel or short story is, but rather a technical description of a story that allows the various people involved to do their jobs: http://www.tjradcliffe.com/?p=1666
Screenplay structure is so tight and formal it's almost like poetry, an analogy I found very useful.
I'm an experimental physicist, and the process for me was more like setting up an experiment, from early ideas to failed prototypes to little side explorations to a final result with (hopefully) all the loose ends tied neatly away where the reader can't see what went into the making.
I agree with what you're saying... a novel is the end product, a screenplay is a blueprint. It took me 4 years to write the novel (admittedly very on and off) and ~3 months to write each of the screenplays. Hopefully my next novel will be faster.
What was your experience of writing both formats in terms of time and effort?
My novel took 5+ years of blood, sweat and re-writes.
Writing a passable screenplay took five days, about six hours a day (evenings 6 - midnight). I don't expect I'll ever sell it, but I'm as certain as anything that it's better than a lot of screenplays that have been sold.
I'm mostly a poet, and love structure. Once I understood the structure of a screenplay, it just happened. Novels in contrast are these huge unstructured messy awkward wobbling teenage flailing morasses. The lack of structure, the lack of constraint, the lack of form is something I struggled with for a long time, and while I expect my next effort won't be quite as painful, I don't ever expect it to be easy.
"Form is liberating", as the engineer's proverb goes. Novels don't have it, and are therefore much more work.
Congratulations on getting the book written and on Amazon. I hope to follow in your footsteps in the coming year.
Like you, I'm fascinated by story structure, the hero's journey, and the mono-myth. And I've struggled with creating something less than flat characters.
I've read the Snowflake method, and parts of it definitely work for me. Another book that I highly value is Dwight Swain's Technique's of the Selling Writing. This was one of the first books that I read on writing fiction, and I still think it's one of the best. I would also recommend Baboulene's, The Story Book, for it's discussion on subtext.
Unfortunately for me, the focus on technique left me not only with flat characters but also a severe case of writer's block. However, I may have found a solution to both problems in John Dufresne's Is Life Like This? Dufresne advocates a more organic, even serendipitous, approach to story creation. For him at least, the results can be wonderful (read his Love Warps the Mind a Little, or his short stories in Johnny Too Bad), and for me, it's got me writing (finally!) and seeing my characters as something more than just cardboard cutouts. Like anything else, it's not for everybody, and YMMV.
The first book I've read that really resonated with me about giving life to characters is The Screenwriter's Bible by David Trottier. BTW, I've read a lot more books about screenwriting than about writing novels, but I believe both apply... stories are stories.
I wasn't good in math, languages or anything in elementary school.
I didn't want to be there and always played "sick".
This just got a little bit better, when I left elementary school and switched 2 schools afterwards. Since the second school was a lot easier than the first, I got better grades without doing anything.
But I never got really good at anything at school, better in Science than in Humanities, always a B- on average. Even my degrees got that rating...
It is probably not worth extrapolating from elementary school performance. And it is probably even less useful to use grades as a measure of success at anything other than doing schoolwork.
It's been said that a programmer's brain is more akin to that of a writer than a mathematician, allegedly because learning programming languages is much like learning a language - the same areas of the brain are involved.
> Scientists are finding that there may be a deeper connection between programming languages and other languages then previously thought. Brain-imaging techniques, such as fMRI allow scientists to compare and contrast different cognitive tasks by analyzing differences in brain locations that are activated by the tasks. For people that are fluent in a second language, studies have shown distinct developmental differences in language processing regions of the brain. A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking.
Hey software engineers, write some m*ther f!cking documentation! Don't tell me it goes out of date, at the very least a module level, architectural overview is better than nothing, and should remain relevant past your tenure.
How do you feel about the saying that code itself should be as good as documentation?
I personally prefer to read the documentation while skimming the code as well but sometimes, when I am under the pressure of having to deliver something, I absolutely despise not having proper documentation so I tend to agree with you.
> How do you feel about the saying that code itself should be as good as documentation?
Not him, but I'll take a crack at it: adorable, high-minded, and wrong. Most people are not going to walk through your code to grasp it in its entirety; design, and document, accordingly.
At the very least, you should have exhaustive, well-considered, commented unit and integration tests to demonstrate its use cases and (foreseeable) failure modes.
Standard HN car analogy time. "Look at the code" is like telling a car mechanic trying to replace a part to look real closely at a high res pix of the factory, instead of reading the Haynes manual.
>> How do you feel about the saying that code itself should be as good as documentation?
The truth is, 95% of developers do not write readable code. But I've been doing this for a while, so I can follow pretty much anything. It's the shear volume of legacy code in the typical code base thats the problem.
What kills me is dead code that you don't know is dead; hundreds of class files, dto's, booleans passed around to control processing that are always false now, because that alternate path is no longer used. And protocol messages, oh god the hundreds of protocol messages, but we only use 10 now.
Edit; I've been the hero more than once documenting stuff like the above.
Code doesn't capture intent in many critical cases, so figuring out what a piece of code is supposed to do is different from figuring out what it does. This is true in part because there are very different levels of abstraction involved.
This could be described as "take the square root of the sum of three values and then divide each value by the result" or "renormalize a vector". The latter is by far the more meaningful and useful description because it is presented at the level of abstraction that the user is likely interested in.
You could say "well why not create a function called 'renormalize_vector' so it would be self-documenting?" Fine, but now you have a function call per renormalization and that has a cost that may be unacceptable. For many simulations renormalizing vectors with a norm near unity is a big overhead, to the extent that I've written custom code to handle that special case and implement it as a macro that I could call "FAST_RENORM_NEAR_UNITY"... but what does "near unity" mean? And what trade-offs went into the design choices? What code isn't there because I tried it and it didn't work well?
People who advocate self-documenting code generally talk as if self-documenting techniques come at zero cost (adding a function call is an unacceptably high cost in some cases) and that the code that exists adequately captures all the thinking that went into it (it does not and cannot.)
So while I'm all for as much self-documentation as possible, any non-trivial code is going to require additional documentation to a) describe the purpose in high-level terms and b) capture the alternatives that were rejected and why.
Unfortunately, for open source projects especially, there is a law of documentation that says power*documentation=constant, so the most powerful code has the worst documentation, and there are projects with great documentation that simply don't do much.
This a hundred times. Comments should always be about intent; never about what's actually happening (the mechanistic description). I don't need help understanding the code as read; I need to know WHY the code was written. So I can debug, follow code paths, skim.
A further advantage: such comments have longer halflives. A rewritten method may still have the same purpose long after all details are changed.
> but now you have a function call per renormalization and that has a cost that may be unacceptable.
I would go for the function, and pass along Knuth's advice about premature optimization. If you're writing at such a low level that function calls actually aren't acceptable, go with a comment "// renormalize vector." Your instinct should be the function though. I bet there is more than one vector normalization going on in this hypothetical codebase, and that line looks pretty typo-prone.
Yes that is a problem. However the question is what do you prefer, no documentation, or documentation that may be out of date? As a detective (which let's face it that is what an Enterprise programmer's job is to an extent) it is nice to have some information which you can scrutinize, rather than nothing.
Where I grew up the distinction didn't happen until high school, and even then there was a large overlap between AP Calculus and AP English. Computer Science was a different beast - we were a subset of the Math nerds that didn't necessarily get into English due to the imprecision.
The irony is that the precision of CS makes us better writers because we can see the inconsistencies. (How many requirements documents can be interpreted multiple ways?) Between undergrad and grad the Math/Verbal spread on my standardized tests flipped.
"Even if nobody reads your essay, writing it will make an impact on you."
After reading a post in HN (https://news.ycombinator.com/item?id=5614689) entitled "why you should write every day", I've being doing it daily in a private blog. I do it in English to improve my second language. My main language is Portuguese.
I'm doing it since 09/22/2014. I try to write about my own ideas, because I believe is the right thing to do and it is the best subject to improve myself. It's not an easy task, and I do not feel I'm improving yet, but something in me tell me that I should keep doing it.
On the other hand, having other people read what you have written can be quite a thrill (especially if it becomes popular). Submitting your blog posts to HN and reddit/r/programming also can get you good feedback and alternative views (and, for that matter, mean comments too).
Tangential - Just want to give you some feedback on your comment, since you are wanting to improve your second language:
First: you've overcome a big hurdle in learning a second language, I understood what you are trying to communicate, and I did so on my first reading of it. To me, this means you're already good at english! (By comparison if I tried in my second language, which is German, I would need a few drafts and a proof-reader).
Second: You're doing commas better than a lot of native english speakers. That's pretty impressive.
Third: There are a couple of grammatical/phrasing errors I'll tell you about in your comment. These are really common errors amongst people who learn English as a second (or Nth) language, and I'm not doing it to belittle you, but to help your stated goal of improvement.
I'm doing it since 09/22/2014
This is one of those wierd places in English where the verbs "to do" or "to be" combine strangely with tenses and idioms. I'm not so sure of the technical way of stating the problem, but here's a couple of examples of a more natural way to state it:
* I've been doing it since 09/22/2014.
* I've done it since 09/22/2014.
but something in me tell me that
This is a small one, and maybe a typo, but it is part of a pattern I've seen a lot. Again, not great at the technical grammar terms, but it should be:
* but something in me tells me that
(notice the 's' on tells).
Anyway I'm always impressed with people who can learn a second language well, and wanted to encourage it and help if can.
Oh, I really appreciate your corrections, thank you!
I understand that reading bad English is really annoying for natives. I try to be careful here on HN, but sometimes I do some mistakes.
You're welcome. Personally, I don't understand when people get annoyed by those things. I figure if someone has done me the favor of learning my language to communicate with me, and they've done so well enough that I understand them, why should I nitpick little errors?
I only point out things like this to people who state they are actively trying to improve - because they've done me a favor by being able to communicate with me, and I can return it by helping them at their goal.
That's a good outlook. I can't tell you how much it irks me when someone is annoyed that someone else doesn't speak English well. I always say "at least their English is better than your <other language>".
Invariably, that outlook is expressed by people who happen to only speak one language.
I don't mind when I meet someone in normal daily activities that speaks English poorly. My thoughts on the subject mirror your own.
What _IS_ frustrating is dealing with a customer service representative in an overseas call center that speaks English poorly. How many man hours have been lost in forced communication with foreign contractors in an effort to save a few dollars an hour over an American counterpart? Also, those cost savings to a company like Comcast also damage our economy by not employing Americans in need of work. It's a double-whammy of frustration.
Your English is not "bad". There are some technical grammar issues you'll continue to work out, but the meaning in your writing is perfectly clear. That makes it pretty easy to overlook anything that's not quite correct in your writing.
I know you said you write on a personal / private blog of your own to improve but if you ever wanted another person to look things over and help you work through some of the trickier parts of learning the language I'd love to help out!
It would be nice, but I haven't cogitated to do this before. I write too much personal things, maybe it is boring for other people, moreover I do not know if this is a good idea, once I will be too much exposed. First I would need to check what I wrote.
Well, I don't know what I have to offer to you in terms of a promise that I won't judge you or pry too deeply into your private life but I really have no good reason to do so. I will gladly share with you all that you want to know about me before we get started if you would like. I really just love helping people out, especially with technology. I started out working towards a career in education (with 12 years of experience) but changed over to programming and web development which is my current career. At some point I want to loop back around and teach some sort of technology discipline to come full circle with my original intentions.
I think non-native English speakers think we are more annoyed by it than we actually are.
Any native English speaker who goes online has to be used to English being used very poorly by now, and it is much less annoying when the person making mistakes is a non-native speaker trying to learn rather than a native speaker who is lazy or functionally illiterate.
Everything you've written is completely understandable and most of it is arguably grammatically okay though sometimes phrased in ways that sound unnatural in colloquial English. For example "sometimes I do some mistakes" would be better said "sometimes I make mistakes", though the way you phrased it is perfectly understandable.
For sure! But I can't think like that, because if I do I will be too much comfortable and stop trying to improve it.
I also sell some simple software overseas and, for doing business, if you have a bad grammar or a poor vocabulary, you loose points in the price negotiation. The other part can feel like they are negotiating with a hick.
Furthermore, everything you write on web will be technically forever, you need to delight the readers and poor English can annoy them, as I've already commented.
It often seems like most use on Hacker News gets this wrong (so it isn't surprising people pick up bad habits when learning English) and I regularly have to resist my inner pedant.
If the screw is too loose it could fall off and you might lose it.
For a counter-point, I'm slightly proud of how our (English) language is able to flexibly accommodate a vast array of other-language grammars, while still maintaining understanding and clarity.
The two points that the previous poster highlighted: while perhaps the native-fluent speaker will notice that the phrases have a non-standard form, both sentences are completely intelligible.
Living abroad from the United States has only served to stretch my conception of "proper English" even further.
This really makes me happy. I never left the country, and my first international travel will be to Melbourne in February/2015 where I will can test myself.
I think the reason why he used commas well (And that many other portuguese speakers use commas better than native english speakers) is that in portuguese you NEED to.
If you don't use commas properly in portuguese, you text can easily get excessively ambiguous, because of that schools here stress the comma a lot, I for example had in my fourth grade entire weeks dedicated to commas, and forgetting commas, even in non-langauge tests (example, in math tests) frequently resulted in some punishment (in math tests forgetting commas resulted into a loss of 0.1 points in the grade for each comma, out of the maximum of 10, thus if your math was correct enough to score 5, but you forgot 5 commas, you would instead score 4.5)
The first bullet is an example of past perfect progressive, which combines the past tense with the perfect and progressive aspects -- in other words, it describes that specific part of an ongoing action (progressive aspect) which has already been (past tense) completed (perfect aspect).
The second bullet exemplifies the past perfect, describing an action which has already been completed, without the additional progressive aspect to signify that the action is ongoing.
Both are correct, and would likely be understood to mean the same in colloquial usage; the only difference is that the former is somewhat more specific than the latter, in stating that the action is ongoing rather than leaving that to be inferred.
This is a slightly unusual case in English, in that otherwise regular verbs almost always take a trailing (e)s in their third-person singular present-tense form. For example, conjugating to tell in the present tense:
1st person: I tell; we tell
2nd person: you tell; you tell
3rd person: he tells; they tell
Presumably this exception exists for historical reasons; why we keep it around, save habit, I have no idea. In any case, we do it with more or less all English verbs, save a few:
> > I'm doing it since 09/22/2014
>
> This is one of those wierd places in English where
> the verbs "to do" or "to be" combine strangely with
> tenses and idioms. I'm not so sure of the technical
> way of stating the problem,
If I'm not mistaken, the technical issue is that "I'm doing" is in the Present Progressive tense/aspect (an ongoing event in the present), which doesn't match having the past date there. "I've been doing" is in the Present Perfect Progressive tense/aspect (an event beginning in the past, but continuing into the ongoing present).
Have you seen http://750words.com/? It's an awesome tool that does exactly that and gives you some insights and game mechanics to make the exercise more interesting
Additionally, I've found that writing out the problem or solution in plain English sometimes helps me make the leap from conceptualizing to actually understanding.
In "physics land" Richard Feynman is famous for his explanatory power, e.g. We tried to take advantage of Richard's talent for clarity by getting him to critique the technical presentations that we made in our product introductions. Before the commercial announcement of the Connection Machine CM-1 and all of our future products, Richard would give a sentence-by-sentence critique of the planned presentation. "Don't say `reflected acoustic wave.' Say [echo]." Or, "Forget all that `local minima' stuff. Just say there's a bubble caught in the crystal and you have to shake it out." Nothing made him angrier than making something simple sound complicated.
I enjoy also the Alan Perlis line, "You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program."
I have been endeavoring to get in the habit of writing about things that I learn. My main obstacle is the feeling that, even if I can write and explain the topic well, other people can too and already have; so why bother writing about it? But that misses the point -- or even two points.
The writing helps me; the fact that someone else wrote is irrelevant. Further, my writing, even if the subject matter is hardly original, might in fact help someone else: not everyone favors the same calculus textbook, or the same Python programming manual, or the same history of World War II. People enjoy different writing styles, different perspectives, even different fonts and page layouts. (I've elected against buying at least one book because I found the page layout excessively annoying to look at!)
There's a similar one from Churchill when asked by a frustrated colleague to get to the point: "How can I know what I think until I hear what I say?"
I think a lot of writers are like this: we are painfully aware of our ignorance, our uncertainty, our lack of belief. The struggle to articulate our beliefs is a struggle to form them. Non-writers often seem to "just know" what they think, which is to me quite remarkable. But they also frequently lack the tools to analyze their beliefs and how they are constructed, because they never have to go through the slow and painful process of figuring them out.
When I first moved to the valley (as a writer) I found I had so much in common with my new friends who were software engineers. Our personality traits were similar, and we wore hoodies and stayed up all night. I'm actually a brilliant math student but writing was the skill set I pursued. I'm really glad you wrote this -- there are so many fascinating parts of software engineering and bright minds whom I would love to learn more insights from!
I agree with the article's arguments. I've been programming since age 10. Doing creative writing almost as long. As an adult ended up doing software engineering as my career. But wrote and published a fiction book two years ago (The Dread Space Pirate Richard, an adventure comedy), close to finishing its sequel (The Man in Black) and also have my first technical book (Software Performance & Scalability) under development. Also written a screenplay and many short stories.
I've found a lot of overlap, in thought process, between programming and writing. Also with music and math. Leverage everything that helps, I think.
I write a blog[1] and I try to add good documentation to my open source project[2], but I recognize that I'm in the minority. One benefit I get from writing, even though I don't get a lot of readers, is thought refinement. I usually send my blog posts to friends and family for help on word choice and better delivery. Even though Steve Jobs said people don't read, I think reading and writing are critical because you don't always have a camera or a microphone to get your message across.
Wow, gitignore is an OSS project?! Didn't know this. Are you looking for collaborators? Love your project and have been looking for something to tinker with on free time. Kudos for great work!
The gitignore.io site is OSS as well as the gitignore template list maintained by GitHub. If you want to collaborate that would be cool, although there isn't much the site does :). All I've been doing recently is merging pull requests and updating submodule.
>> "Even though Steve Jobs said people don't read"
Source on this? As a general statement that sounds kind of ridiculous. I would have thought people are reading more than ever considering how much of the internet is text. Also a little strange considering Apple runs a bookstore.
It was from the New York Times [1] they asked Steve about the Kindle reader.
> “It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore,” he said. “Forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.”
So it seems like he meant books specifically. Still strange considering he then opened iBooks but I guess this was a case of Apple being on the back foot.
Because of my own ignorance, I'd assumed The Economist Style Guide was another tome mainly full of usage rules. Having actually looked at a bit of it now, it seems much more accessible and useful than that.
To paraphrase Knuth, "programming is explaining to another human being what you want a computer to do."
Should you take it to the extreme Knuth did with Literate Programming? I personally don't. But, once I've successfully explained to the computer what it should do (my program works) I look for ways to better communicate what it's doing (my program is readable). In many cases that's harder than solving the technical problem at hand.
Concision and simplicity seem to be the key to that. I agree with the author that "like good prose, good code is concise," although for prose that's more a matter of taste. Otherwise we'd all be reading a lot more Hemingway.
I think this is one of the main benefits I find on HN. Not only does this give me an intelligent, well educated community to talk to, but most often the community shares my hobbies and interests.
I think being able to write is extremely important, but I think the rhetoric behind writing is just as important, if not more important. When you write in a community or forum, like HN, citing your sources and defending your arguments is more important than on a blog, because if you don't, your voice simply won't be heard as loudly.
Contrast this with clickbait blogs, or blogs that simply write for shock, it because clear that having a humorous or convincing writing style is almost as important as being able to argue your point, or convey a complicated idea. However, in my mind I find the latter a far more important skill in the long run.
So yes, software engineers should write, but also don't forget to do some 'code' reviews.
165 comments
[ 6.3 ms ] story [ 206 ms ] threadI can't decide if that was deliberate or not.
I'd do it again, and I recommend anybody that gets the change to do it as well.
I learned these optimization techniques later in my grad school studies (a very critical adviser helped), never learning how to really write as a CS undergrad. Now I am the go-to guy for paper editing, and I find it frustrating that I can't seem to teach this to those I help write papers.
As writers say, know your audience.
Yes, but most of the time it's more important that a human can understand it easily than it is for it to be the most efficient code in the world.
A few weeks ago I read a quote about someone saying that good code should be 'self-documenting' and that it should be obvious what it does. This is a red herring -- it assumes you wrote code that works perfectly. If there is a bug in your 'self-documenting' code, then how is someone supposed to know if it is wrong or not?
As for audience, when coding you can consider your audience to be both humans that follow you, as well as the machine it is running on.
In my opinion, programming has always been a form of writing. Just like songwriting is a form of writing. It's simply a different medium, and therefore you get a different result.
I might be looking at it from a different kind of lens though.
[0] http://www.nostarch.com/hemingwayjs
Very good point!
This is the strongest "pitch" for why one should learn math: the modelling superpowers one will acquire. Every function f(x) is a type of model (e.g. mx+b, x^2, e^x, ln(x), cos(x), |x|, etc.), and understanding the function f(x) will allow you to model any phenomenon that exhibits f(x)-like behaviour.
[note: I'm working on the web copy for a math book and trying to decide what to put above the fold to make the average Internet reader interested in math. So far the shortlist of pitches are (1) learn math easily because the book is short and written in a chill tone, (2) destroy your calculus and mechanics exams (for students), (3) get rid of math phobia (for English kids), and (4) gain modelling superpowers. So far I like (4) the best. What do y'all think? Any feedback would be much appreciated. ]
I agree with you generally, but if you compare with the current math textbooks (that students are usually forced to buy) you will concede there is a lot of room for improvement on the textbook side.
Also, while I think technology might be cool to play with, nothing beats the book as a medium for the transmission of information.
I did very well at English at school, but failed hard at maths whilst freelancing from home after teaching myself PHP.
I really wish I'd engaged (and was taught) maths in the same way as I did with code - I remember feeling quite annoyed at the way I was being taught maths which was basically "when you see a question asked in this way, you answer it by following these steps". I think if I'd been taught maths through experimentation and having "projects" to solve in the same way I learned to code, I would've been quite a good maths student.
Those classes probably turned off a sad number of would-be good writers from learning how to write creatively, efficiently, or even reasonably. I had exactly one English teacher who was reasonable and only taught to these abominable standards as required by the state but let real writing be rewarded in other assignments; he understood the reality of the language and that the point of your writing should be moreso effectively articulating ideas, effecting desired emotional responses, or provoking thoughts rather than some nonsense a committee at the Department of Education decided is proper and that legions of English teachers across the country take to heart as dogma and revel in the sadism of. Otherwise, throughout the years it was splitting hairs over prescriptivist grammatical minutiae, the aforementioned ridiculous essay structure, memorizing obsolete Shakespearen-era "vocabulary words" that no writer writing for a living audience would even consider using, and going on about how any grammatical structure or word that appeared after 1900 is objectively wrong.
I could have put much less effort into them than I did and still gotten As but I preferred to use them as an exercise in trying to work good writing around the myriad deeply-rooted problems in how I was forced to present it. That's the only bonus point I can give to it as a learning environment.
English classes in college have just been the same disappointment with a different mask on for the most part, except for exposure to real research methods, but still lag behind the real world in forcing you to use non-internet sources.
Was the experience different for you?
I also disliked the emphasis on literary analysis. It so often seemed like contrived flimflammery crossed with psychoanalytic mumbo-jumbo. If tvtropes (or allthetropes) had existed back then, I think I would have performed much better on my English homework. After all, those sites do include the Jungian archetypes and the basic plots as a subset.
As it is, my high school English classes drove me far away from anything even remotely similar until a lifetime of reading fiction, a shameful amount of blathering on Internet message boards, and the exhortations of the "National Novel-Writing Month (NaNoWriMo)" organization convinced me to try to write a novel in November of 2012. Two years later, I have written 500 kb, with maybe 130 kb left to go before I snap it off and start the next one. Then there's also the matter of the default HTML stylesheet, continuity notes and timelines, the character, vehicle, location, and artifact indices, working hyperlinks, and testing the release version on all available e-reader programs and devices.
As for my old English teachers, I bite my thumb at them, like Sampson. I give them the fig, like Vanni Fucci. And just as golf is a good walk, spoiled, English class is a good read, ruined. Even with those ancient cultural references rattling around my bonebox, I find that an increasingly large fraction of my memes are drawn from television, film, music, video games, and popular web sites, and a vanishingly small portion from the old literary canon.
That's how I know that the Belmonts love Devo. If you understand why, you probably won't need to thank an English teacher.
All I really ever needed was a pile of books that I enjoyed reading and a copy of Strunk and White (minus the part about always putting sentence punctuation inside the quotes, because that's just madness). What I got was about 10 years of pedagogical torture that discouraged me from trying something that turned out to be a fun hobby.
I've actually found that it helps me think about more of the big picture stuff. In writing my first post about one of our APIs [1] I actually realized that there was a small omission in how we designed it.
[1] http://exosite.com/real-time-device-communication-part-1/
It's possible to stay as an average engineer for a long time, but if you want to try being an Architect, then at least 50% of your time is spent writing or public speaking. If you want to be an engineering manager, that's over 90%.
Fortunately a company I used to work for believed pretty strongly in cultivating these "soft skills", so they incentivized things like Tech Talks, and covered the cost of courses like Dale Carnegie.
Have you written anywhere about the things this company did?
The talks were incentivized as part of the bonus structure. If the company did well, and you completed your goals, then you could get up to X% of your salary as a bonus. (Also, they usually included free lunch)
The technology and the people at that company were really great to work with - I probably got more experience in one year there than five years at any other company. Unfortunately it was in the advertising business, so many of the business practices were slimy and cutthroat. (It seemed like every month we had a crisis where either Google, Microsoft, or Apple didn't like what we were doing and wanted to shut it down.)
I got the important takeaway from that experience, but many people do not, and it is a shame.
As a hobby I've done a lot of reading around this; I've written three feature-length screenplays, and a novel you can find in Amazon[1], using very structure-centric approaches (as a result, my characters tend to be too flat).
Take a look at The Snowflake Method[2], unsurprisingly designed by a novelist who is also a theoretical physicist. Even with The Hero's Journey, there's a surprising amount of well-understood structure behind every story.
[1] http://www.amazon.com/dp/B00QPBYGFI [2] http://www.advancedfictionwriting.com/articles/snowflake-met...
I'm curious - do you know why that particular pistol was chosen for your cover?
The cover was made by a freelancer I found on 99designs.com (I'm really happy about that experience, BTW - and I have nothing to do with them, I just liked the service). The pistol looks good and the image was royalty-free, which is probably why the freelancer chose it.
But in retrospect you're right, I should have checked. The only pistol specifically mentioned in the novel is a "H&K" (not even the model), but there are many other anonymous ones. This CZ-75 could be one of these :)
Screenplay structure is so tight and formal it's almost like poetry, an analogy I found very useful.
My novel (http://www.amazon.com/Darwins-Theorem-TJ-Radcliffe-ebook/dp/...) was developed much more organically.
I'm an experimental physicist, and the process for me was more like setting up an experiment, from early ideas to failed prototypes to little side explorations to a final result with (hopefully) all the loose ends tied neatly away where the reader can't see what went into the making.
I found Stephen King's book on writing to be one of the best for understanding the organic process of creating stories. If you haven't read it, I'd strongly recommend it: http://www.amazon.com/Writing-Stephen-King-ebook/dp/B000FC0S...
I agree with what you're saying... a novel is the end product, a screenplay is a blueprint. It took me 4 years to write the novel (admittedly very on and off) and ~3 months to write each of the screenplays. Hopefully my next novel will be faster.
What was your experience of writing both formats in terms of time and effort?
My novel took 5+ years of blood, sweat and re-writes.
Writing a passable screenplay took five days, about six hours a day (evenings 6 - midnight). I don't expect I'll ever sell it, but I'm as certain as anything that it's better than a lot of screenplays that have been sold.
I'm mostly a poet, and love structure. Once I understood the structure of a screenplay, it just happened. Novels in contrast are these huge unstructured messy awkward wobbling teenage flailing morasses. The lack of structure, the lack of constraint, the lack of form is something I struggled with for a long time, and while I expect my next effort won't be quite as painful, I don't ever expect it to be easy.
"Form is liberating", as the engineer's proverb goes. Novels don't have it, and are therefore much more work.
Like you, I'm fascinated by story structure, the hero's journey, and the mono-myth. And I've struggled with creating something less than flat characters.
I've read the Snowflake method, and parts of it definitely work for me. Another book that I highly value is Dwight Swain's Technique's of the Selling Writing. This was one of the first books that I read on writing fiction, and I still think it's one of the best. I would also recommend Baboulene's, The Story Book, for it's discussion on subtext.
Unfortunately for me, the focus on technique left me not only with flat characters but also a severe case of writer's block. However, I may have found a solution to both problems in John Dufresne's Is Life Like This? Dufresne advocates a more organic, even serendipitous, approach to story creation. For him at least, the results can be wonderful (read his Love Warps the Mind a Little, or his short stories in Johnny Too Bad), and for me, it's got me writing (finally!) and seeing my characters as something more than just cardboard cutouts. Like anything else, it's not for everybody, and YMMV.
Good luck, and keep writing!
The first book I've read that really resonated with me about giving life to characters is The Screenwriter's Bible by David Trottier. BTW, I've read a lot more books about screenwriting than about writing novels, but I believe both apply... stories are stories.
I wasn't good in math, languages or anything in elementary school.
I didn't want to be there and always played "sick".
This just got a little bit better, when I left elementary school and switched 2 schools afterwards. Since the second school was a lot easier than the first, I got better grades without doing anything.
But I never got really good at anything at school, better in Science than in Humanities, always a B- on average. Even my degrees got that rating...
Developers and designers, tech and sales, front- and backend...
From http://www.huffingtonpost.com/chris-parnin/scientists-begin-...
> Scientists are finding that there may be a deeper connection between programming languages and other languages then previously thought. Brain-imaging techniques, such as fMRI allow scientists to compare and contrast different cognitive tasks by analyzing differences in brain locations that are activated by the tasks. For people that are fluent in a second language, studies have shown distinct developmental differences in language processing regions of the brain. A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking.
/rant
I personally prefer to read the documentation while skimming the code as well but sometimes, when I am under the pressure of having to deliver something, I absolutely despise not having proper documentation so I tend to agree with you.
Not him, but I'll take a crack at it: adorable, high-minded, and wrong. Most people are not going to walk through your code to grasp it in its entirety; design, and document, accordingly.
At the very least, you should have exhaustive, well-considered, commented unit and integration tests to demonstrate its use cases and (foreseeable) failure modes.
The truth is, 95% of developers do not write readable code. But I've been doing this for a while, so I can follow pretty much anything. It's the shear volume of legacy code in the typical code base thats the problem.
What kills me is dead code that you don't know is dead; hundreds of class files, dto's, booleans passed around to control processing that are always false now, because that alternate path is no longer used. And protocol messages, oh god the hundreds of protocol messages, but we only use 10 now.
Edit; I've been the hero more than once documenting stuff like the above.
To take a trivial example:
norm = sqrt(x[0]2 + x[1]2 + x[2]2) x[0] /= norm x[1] /= norm x[2] /= norm
This could be described as "take the square root of the sum of three values and then divide each value by the result" or "renormalize a vector". The latter is by far the more meaningful and useful description because it is presented at the level of abstraction that the user is likely interested in.
You could say "well why not create a function called 'renormalize_vector' so it would be self-documenting?" Fine, but now you have a function call per renormalization and that has a cost that may be unacceptable. For many simulations renormalizing vectors with a norm near unity is a big overhead, to the extent that I've written custom code to handle that special case and implement it as a macro that I could call "FAST_RENORM_NEAR_UNITY"... but what does "near unity" mean? And what trade-offs went into the design choices? What code isn't there because I tried it and it didn't work well?
People who advocate self-documenting code generally talk as if self-documenting techniques come at zero cost (adding a function call is an unacceptably high cost in some cases) and that the code that exists adequately captures all the thinking that went into it (it does not and cannot.)
So while I'm all for as much self-documentation as possible, any non-trivial code is going to require additional documentation to a) describe the purpose in high-level terms and b) capture the alternatives that were rejected and why.
Unfortunately, for open source projects especially, there is a law of documentation that says power*documentation=constant, so the most powerful code has the worst documentation, and there are projects with great documentation that simply don't do much.
A further advantage: such comments have longer halflives. A rewritten method may still have the same purpose long after all details are changed.
I would go for the function, and pass along Knuth's advice about premature optimization. If you're writing at such a low level that function calls actually aren't acceptable, go with a comment "// renormalize vector." Your instinct should be the function though. I bet there is more than one vector normalization going on in this hypothetical codebase, and that line looks pretty typo-prone.
I guess it is more acceptable to have a bug in the code than a mistake in the documentation.
The irony is that the precision of CS makes us better writers because we can see the inconsistencies. (How many requirements documents can be interpreted multiple ways?) Between undergrad and grad the Math/Verbal spread on my standardized tests flipped.
After reading a post in HN (https://news.ycombinator.com/item?id=5614689) entitled "why you should write every day", I've being doing it daily in a private blog. I do it in English to improve my second language. My main language is Portuguese.
I'm doing it since 09/22/2014. I try to write about my own ideas, because I believe is the right thing to do and it is the best subject to improve myself. It's not an easy task, and I do not feel I'm improving yet, but something in me tell me that I should keep doing it.
"I've /been/ doing it since ..." Concordo. Acho que deve continuar escrever. De onde você é?
I agree. You should continue to write. Where are you from?
First: you've overcome a big hurdle in learning a second language, I understood what you are trying to communicate, and I did so on my first reading of it. To me, this means you're already good at english! (By comparison if I tried in my second language, which is German, I would need a few drafts and a proof-reader).
Second: You're doing commas better than a lot of native english speakers. That's pretty impressive.
Third: There are a couple of grammatical/phrasing errors I'll tell you about in your comment. These are really common errors amongst people who learn English as a second (or Nth) language, and I'm not doing it to belittle you, but to help your stated goal of improvement.
I'm doing it since 09/22/2014
This is one of those wierd places in English where the verbs "to do" or "to be" combine strangely with tenses and idioms. I'm not so sure of the technical way of stating the problem, but here's a couple of examples of a more natural way to state it:
* I've been doing it since 09/22/2014.
* I've done it since 09/22/2014.
but something in me tell me that
This is a small one, and maybe a typo, but it is part of a pattern I've seen a lot. Again, not great at the technical grammar terms, but it should be:
* but something in me tells me that
(notice the 's' on tells).
Anyway I'm always impressed with people who can learn a second language well, and wanted to encourage it and help if can.
I only point out things like this to people who state they are actively trying to improve - because they've done me a favor by being able to communicate with me, and I can return it by helping them at their goal.
Invariably, that outlook is expressed by people who happen to only speak one language.
What _IS_ frustrating is dealing with a customer service representative in an overseas call center that speaks English poorly. How many man hours have been lost in forced communication with foreign contractors in an effort to save a few dollars an hour over an American counterpart? Also, those cost savings to a company like Comcast also damage our economy by not employing Americans in need of work. It's a double-whammy of frustration.
Strawman.
> Invariably, that outlook is expressed by people who happen to only speak one language.
Confirmation bias.
0/2. Congrats! Your comment contributed to the topic about as much, if not less, than mine. Happy Holidays! <3
Try "considered" or "thought about".
"Cogitated" is very similar with the Portuguese translation "Cogitado", broadly used. And on Google Translate it appears as the first option.
I think that literature and travel are the keys to improve on this.
Any native English speaker who goes online has to be used to English being used very poorly by now, and it is much less annoying when the person making mistakes is a non-native speaker trying to learn rather than a native speaker who is lazy or functionally illiterate.
Everything you've written is completely understandable and most of it is arguably grammatically okay though sometimes phrased in ways that sound unnatural in colloquial English. For example "sometimes I do some mistakes" would be better said "sometimes I make mistakes", though the way you phrased it is perfectly understandable.
I also sell some simple software overseas and, for doing business, if you have a bad grammar or a poor vocabulary, you loose points in the price negotiation. The other part can feel like they are negotiating with a hick.
Furthermore, everything you write on web will be technically forever, you need to delight the readers and poor English can annoy them, as I've already commented.
http://www.merriam-webster.com/dictionary/loose http://www.merriam-webster.com/dictionary/lose
This is a common error for the natives as well so don't feel bad about it.
[Edit: I a word]
If the screw is too loose it could fall off and you might lose it.
The two points that the previous poster highlighted: while perhaps the native-fluent speaker will notice that the phrases have a non-standard form, both sentences are completely intelligible.
Living abroad from the United States has only served to stretch my conception of "proper English" even further.
This really makes me happy. I never left the country, and my first international travel will be to Melbourne in February/2015 where I will can test myself.
I think the reason why he used commas well (And that many other portuguese speakers use commas better than native english speakers) is that in portuguese you NEED to.
If you don't use commas properly in portuguese, you text can easily get excessively ambiguous, because of that schools here stress the comma a lot, I for example had in my fourth grade entire weeks dedicated to commas, and forgetting commas, even in non-langauge tests (example, in math tests) frequently resulted in some punishment (in math tests forgetting commas resulted into a loss of 0.1 points in the grade for each comma, out of the maximum of 10, thus if your math was correct enough to score 5, but you forgot 5 commas, you would instead score 4.5)
http://en.wikipedia.org/wiki/Uses_of_English_verb_forms#Prog...
The first bullet is an example of past perfect progressive, which combines the past tense with the perfect and progressive aspects -- in other words, it describes that specific part of an ongoing action (progressive aspect) which has already been (past tense) completed (perfect aspect).
The second bullet exemplifies the past perfect, describing an action which has already been completed, without the additional progressive aspect to signify that the action is ongoing.
Both are correct, and would likely be understood to mean the same in colloquial usage; the only difference is that the former is somewhat more specific than the latter, in stating that the action is ongoing rather than leaving that to be inferred.
http://en.wikipedia.org/wiki/English_verbs#Third_person_sing...
This is a slightly unusual case in English, in that otherwise regular verbs almost always take a trailing (e)s in their third-person singular present-tense form. For example, conjugating to tell in the present tense:
1st person: I tell; we tell 2nd person: you tell; you tell 3rd person: he tells; they tell
Presumably this exception exists for historical reasons; why we keep it around, save habit, I have no idea. In any case, we do it with more or less all English verbs, save a few:
http://en.wikipedia.org/wiki/English_irregular_verbs#Verbs_w...
http://en.wikipedia.org/wiki/English_modal_verbs
Writing about a topic is a good test of whether you can explain it simply.
via http://longnow.org/essays/richard-feynman-connection-machine...
I have been endeavoring to get in the habit of writing about things that I learn. My main obstacle is the feeling that, even if I can write and explain the topic well, other people can too and already have; so why bother writing about it? But that misses the point -- or even two points.
The writing helps me; the fact that someone else wrote is irrelevant. Further, my writing, even if the subject matter is hardly original, might in fact help someone else: not everyone favors the same calculus textbook, or the same Python programming manual, or the same history of World War II. People enjoy different writing styles, different perspectives, even different fonts and page layouts. (I've elected against buying at least one book because I found the page layout excessively annoying to look at!)
"I don't know what I think until I try to write it down."
I think a lot of writers are like this: we are painfully aware of our ignorance, our uncertainty, our lack of belief. The struggle to articulate our beliefs is a struggle to form them. Non-writers often seem to "just know" what they think, which is to me quite remarkable. But they also frequently lack the tools to analyze their beliefs and how they are constructed, because they never have to go through the slow and painful process of figuring them out.
I've found a lot of overlap, in thought process, between programming and writing. Also with music and math. Leverage everything that helps, I think.
[1] - https://blog.joeblau.com/
[2] - https://github.com/joeblau/gitignore.io
Source on this? As a general statement that sounds kind of ridiculous. I would have thought people are reading more than ever considering how much of the internet is text. Also a little strange considering Apple runs a bookstore.
> “It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore,” he said. “Forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.”
[1] - http://bits.blogs.nytimes.com/2008/01/15/the-passion-of-stev...
Also, related link on writing: https://news.ycombinator.com/item?id=8793024
Should you take it to the extreme Knuth did with Literate Programming? I personally don't. But, once I've successfully explained to the computer what it should do (my program works) I look for ways to better communicate what it's doing (my program is readable). In many cases that's harder than solving the technical problem at hand.
Concision and simplicity seem to be the key to that. I agree with the author that "like good prose, good code is concise," although for prose that's more a matter of taste. Otherwise we'd all be reading a lot more Hemingway.
I think being able to write is extremely important, but I think the rhetoric behind writing is just as important, if not more important. When you write in a community or forum, like HN, citing your sources and defending your arguments is more important than on a blog, because if you don't, your voice simply won't be heard as loudly.
Contrast this with clickbait blogs, or blogs that simply write for shock, it because clear that having a humorous or convincing writing style is almost as important as being able to argue your point, or convey a complicated idea. However, in my mind I find the latter a far more important skill in the long run.
So yes, software engineers should write, but also don't forget to do some 'code' reviews.