February 4, 2011
I have a confession to make: in a way, I founded Stack Overflow to trick my fellow programmers.
Before you trot out the pitchforks and torches, let me explain.
Over the last 6 years, I've come to believe deeply in the idea that that becoming a great programmer has very little to do with programming. Yes, it takes a modicum of technical skill and dogged persistence, absolutely. But even more than that, it takes serious communication skills:
The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it's not whether they prefer Python or Java. It's whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.
That is of course a quote from my co-founder Joel Spolsky, and it's one of my favorites.
In defense of my fellow programmers, communication with other human beings is not exactly what we signed up for. We didn't launch our careers in software development because we loved chatting with folks. Communication is just plain hard, particularly written communication. How exactly do you get better at something you self-selected out of? Blogging is one way:
People spend their entire lives learning how to write effectively. It isn't something you can fake. It isn't something you can buy. You have to work at it.
That's exactly why people who are afraid they can't write should be blogging.
It's exercise. No matter how out of shape you are, if you exercise a few times a week, you're bound to get fitter. Write a small blog entry a few times every week and you're bound to become a better writer. If you're not writing because you're intimidated by writing, well, you're likely to stay that way forever.
Even with the best of intentions, telling someone "you should blog!" never works. I know this from painful first hand experience. Blogging isn't for everyone. Even a small blog entry can seem like an insurmountable, impenetrable, arbitrary chunk of writing to the average programmer. How do I get my fellow programmers to blog without blogging, to write without writing?
By cheating like hell, that's how.
Consider this letter I received:
I'm not sure if you have thought about this side effect or not, but Stack Overflow has taught me more about writing effectively than any class I've taken, book I've read, or any other experience I have had before.
I can think of no other medium where I can test my writing chops (by writing an answer), get immediate feedback on its quality (particularly when writing quality trumps technical correctness, such as subjective questions) and see other peoples attempts as well and how they compare with mine. Votes don't lie and it gives me a good indicator of how well an email I might send out to future co-workers would be received or a business proposal I might write.
Over the course of the past 5 months all the answers I've been writing have been more and more refined in terms of the quality. If I don't end up as the top answer I look at the answer that did and study what they did differently and where I faltered. Was I too verbose or was I too terse? Was I missing the crux of the question or did I hit it dead on?
I know that you said that writing your Coding Horror blog helped you greatly in refining your writing over the years. Stack Overflow has been doing the same for me and I just wanted to thank you for the opportunity. I've decided to setup a coding blog in your footsteps and I just registered a domain today. Hopefully that will go as well as writing on SO has. There are no tougher critics than fellow programmers who scrutinize every detail, every technical remark and grammar structure looking for mistakes. If you can effectively write for and be accepted by a group of programmers you can write for anyone.
Joel and I have always positioned Stack Overflow, and all the other Stack Exchange Q&A sites, as lightweight, focused, "fun size" units of writing.
Yes, by God, we will trick you into becoming a better writer if that's what it takes – and it always does. Stack Overflow has many overtly gamelike elements, but it is a game in service of the greater good – to make the internet better, and more importantly, to make you better. Seeing my fellow programmers naturally improve their written communication skills while participating in a focused, expert Q&A community with their peers? Nothing makes me prouder.
Beyond programming, there's a whole other community of peers out there who grok how important writing is, and will support you in sharpening your saw, er, pen. We have our own, too.
If you're an author, editor, reviewer, blogger, copywriter, or aspiring writer of any kind, professional or otherwise – check out writers.stackexchange.com. Becoming a more effective writer is the one bedrock skill that will further your professional career, no matter what you choose to do.
But mostly, you should write. I thought Jon Skeet summed it up particularly well here:
Everyone should write a lot – whether it's a blog, a book, Stack Overflow answers, emails or whatever. Write, and take some care over it. Clarifying your communication helps you to clarify your own internal thought processes, in my experience. It's amazing how much you find you don't know when you try to explain something in detail to someone else. It can start a whole new process of discovery.
The process of writing is indeed a journey of discovery, one that will last the rest of your life. It doesn't ultimately matter whether you're writing a novel, a printer review, a Stack Overflow answer, fan fiction, a blog entry, a comment, a technical whitepaper, some emo LiveJournal entry, or even meta-talk about writing itself. Just get out there and write!
Posted by Jeff Atwood
While I agree communication skills are important, I'm not sure you should be quoting Joel Spolsky. While he sounds a great bloke to work for, I've never seen much evidence he has any great ability to write software.
This says it all for me:
"By writing clear comments and technical specs, they let other programmers understand their code"
It's far more important to write clear code, than to write code that needs to be explained by comments and external documents.
But perhaps that what Joel meant, and he just didn't communicate it clearly :-)
Yes you are very correct that communication, especially written communication is extremely important. The irony of you opening paragraph is awesome:
"I've come to believe deeply in the idea that that becoming a great programmer has very little to do with programming"
I think the point is that writing is hard enough even with the whole English language at your disposal.
When you only have the syntax of a programming language, the clearest code in the word is still easier to understand with comments and a tech spec.
Thanks for another excellent and insightful article, you made me realise what I love so much about Quora.
Don't get me wrong I have been recommending SO to people for years, as an example of how crowd sourced Q&A should work. The problem for me personally is that only a very small fraction of my near 15k of network connections are programmers.
While I value crowd source massively it is blown away by connect source. Most of my biggest problems are not 'how does this work?' but 'why does it work?' and 'will it work tomorrow?'.
For those questions, some tenuous path back to the source of the intelligence, some prior knowledge or some common friends are far more important. But as you can see from my answer, you are dead right, it's all about communication skills.
I've always found it strange that, for learning programming and similar subjects, it is easy to find very basic "hello world" tutorials on one hand, and very complex and specific information on the other. This post might be the explanation why.
One reason could be that the intermediate range of knowledge is the hardest to communicate - it regards the logic behind the technical aspects. You have to write sentences understandable to someone who doesn't know much on the subject yet, and you need to know what not to take for granted. And putting something that you understand intuitively in words is not easy. But it is very important. Programmers should put in the effort to put into words the precious knowledge and ways of thinking that are in their heads. I thank anyone who is already doing it or going to do it in the future, including Jeff Atwood, clearly.
But in the end all sharing of knowledge is precious - even the smallest technical detail or personal experience. So do as Jeff suggests in this post. Please:)
I too have started a blog to document my learning process, and I'm finding that now I need to learn blogging as well as programming. Takes practice, but it's very useful. Putting things in my own words also helps me understand them better. I find that if I actually try to explain a subject to myself, in writing, I realize how much do I really know, and which aspects do I need to know better. It helps me move beyond just following my intuition and later getting lost in it. I create maps for myself.
BTW English is not my first language, excuse me for any possible errors.
Finally I have a chance say thank you for this valuable blog. And for Stack Overflow. I keep thinking I need to start participating there actively, as well, but for now I've been reading it and it's wonderful.
Olja Petrovic, http://apprenticecoder.wordpress.com
As much as I agree that communicating ideas are important, I have no issue discussing these things with other programmers.
It's when you write the documents explaining everything to the people distributing the money that it becomes difficult, because most of the time, they don't know shit. They're just some dude with a cheque book and want to know why they should pay for an additional two weeks or why this does that and they want to know how it works... but no details? It can be very frustrating as a lot of these people also tend to be very tech illiterate.
I actually had to tell someone that no, the computer cannot process the data if you turn it off, even if you started it before hand and even though that data is on the server.
Agreed on the importance of communication skills, but there are few professions nowadays where this is not required, so it says nothing about programmers specifically.
I also think that you stereotype programmers a bit too much in the beginning paragraphs. You make it sound like they are all anti-social, projecting the Hollywood cliche onto them. In my own experience working in several large companies with large development teams, I do not see that. I see perfectly "normal" people, with adequate communication skills, a family at home, proper clothing, etc.
It seems everybody fixates on the bearded Debian hardcode C programmer, but reality in my experience is very very far from it.
Yes! You hit the nail on the head, if I can say so.
I'm a programmer and a blogger, and when I learn something new, I try to share my knowledge on my blog. This way, I better understand a new concept or something that is hard for me to understand.
Thank you for this great article.
I like how the design for the Writer's site looks like some sort of drafting design with quad-paper and blue-pencil logo.
Maybe you made a mistake and meant to use that for drafting.stackexchange.com?
Also, to be honest I agree with Jim Cooper -- never really seen anything Spolsky has coded, just the things he's wrote about 'managing programmers'.
Very interesting post. I agree completely. I struggle with writing. Not very good at all but I do attempt it on occasion. I guess I need to spend a little more time with it and see where it goes.
This blog post inspires me to continue blogging on IT and development in this industry in my island after 3 year of blogging on University Student Life and British computer Society.
Coding Horror FTW!
If everybody writes a lot, who's gonna read ? :-)
"Yes, by God, we will trick you into becoming a better writer if that's what it takes – and it always does." -- Seriously? It was not put into you to guide the entire development community whether we like it or not. I love how people always invoke God when they are justifying a lie.
Poor us, just too stupid to see the genius that is Jeff Atwood, so he redirects his entire career in order to build an intricate lie to get us to do what he knows is best for us and we just can't see. Thank you Jeff Atwood for saving us. What would we ever have done without you.
I agree that communication is an important skill, one you could learn more about before trying to guide the world. If you have to lie to convince others to follow merits of your ideas then you are in fact failing at the communication you claim to be so important.
Nothing is more of a curse to the world than people who have become so full of their own intelligence that they believe they are just in deceiving/forcing others to conform to their "enlightenment".
Personally, I think communication plays a big role in programming. But understanding what you are doing plays an even bigger role. It doesn't matter how good of a communicator you are, if you don't understand what you are talking about, you will completely fail at trying to work as a programmer. While I understand that there are many good programmers who just lack communication skills, I very rarely find one who has such bad communication skills that they can't get their point across, If they know what they are talking about. While communication skills can help make a good programmer better, they can't make a programmer who has no idea what they are doing any better.
It's far more important to write clear code, than to write code that needs to be explained by comments and external documents.
Writing comments before code can help you write clear code.
While I can't comment on Joel Spolsky's ability as a programmer, his comment makes sense.
Code alone does not provide context. While you should strive to avoid redundant comments that repeat what the code does, you still need comments and technical specs to tell you why the code even exists and how it fits into the larger picture.
It's also very helpful to point out to developers when you are using certain patterns, algorithms, etc and not expect them to just intuit it from a cleverly named class. At least you should give them enough to google with.
You also should never underestimate the invaluable aspect of writing as a problem solver. Consider how many times any of us have been stuck trying to resolve a sticky technical issue. The process of writing itself can liberate you from your situation. By carefully channeling the conditions of your issue in a linear and comprehensive text, your situation is translated from spatial & abstract to linear & concrete, which often can lead to a resolution.
Just think of how many times you've gone to explain a problem to a coworker and as you explain it, the riddle is solved.
@Russel -- is your humor detector broken? Or maybe you're just prone to taking things a little too literally? Jeff is just taking notice of the effect that SO has had in regard to improving some programmers' writing skills.
Jeff and Joel, did not create StackOverflow and friends to force anyone to improve their writing skills. They did it to make money. (If not, then why are there ads on those sites?) If Jeff notices that the sites have had unexpected beneficial side effects, and writes a slightly tongue in cheek post, with specific examples, that recognizes that effect, big deal. Don't jump the shark and assume they hatched this evil plan from the beginning to trick us all into doing something we would never have done ourselves. I know, I know--Jeff wrote that that is exactly what they did. It's called literary license. Jebus. Take a valium.
Nicely written rant, though...
Improving my writing is one of the important motivations for maintaining a blog in the first place.
It is so inspiring for the people like me who are at the initial stage of writing...
I look forward to reading through this and more. I agree that programming has more to do with communication than with advanced optimization skills, however there is also the topic of good modularization and specification of module interface - something which must then be communicated.
I have had your site bookmarked for a long time and hope to get more time to read and use the inspiration found here for some of my "darling" projects :-)
This line made me think of what I believe is an important principle for building software:
Yes, by God, we will trick you into becoming a better writer if that's what it takes – and it always does. Stack Overflow has many overtly gamelike elements . . .
The idea is that "real life" tasks can be made more interesting by making them more like video games. See the WSJ book review for Reality is Broken. I like this idea a lot, and I think it will improve software UI for all sort of things, if people apply it to their projects. I suspect smartphone development will help motivate such work. I'm building a desktop app right now, and even before seeing the WSJ article, I often asked myself how I could make it more like a video game.
Cleanly and efficiently transferring knowledge in an unambiguous manner is indeed the main purpose of computing science.
An excellent language for doing just that would be first order logic (extended with inductive definitions). The addition of ID makes it a very rich and expressive language, but many computer scientists lack the love of rigor neccessary to fully immerse all their writings in it.
Personally I blame hacking culture.
There is indeed hardly any difference between C++, Java or Python when it comes to readable code, but that doesn't mean that the chosen language doesn't matter. It's like tasting a dozen sorts of apples and concluding fruit isn't your thing.
In my opinion a program is finished only when you have proven it does what you claim it does. No one should trust you on your word, and no one intelligent will. Altough sadly not possible in all cases, formal verification is still an (often disregarded) option when proving your programs. I don't have to tell you that debugging using input and output, even when carefully handling edge cases etc. can still lead to horribly unstable code.
Writing crisp, clean code in a language that encourages formal verification (take Haskell for example) could truly empower all programmers. Letting your programs have a modular architecture is only worthwile when you can assure that the modules you will insert and swap are correct. Whenever possible programmers should enforce themselves to prove the correctness of what they write. It teaches programmers to arrange their thoughts in a structured, methodical manner, it forces one to be efficient, clear and conscise. Anything else is laziness. People who complain about the rigidness of it all are lost. A programmer isn't a creature who has memorized loads of commands and can write some scripts under influence of caffein and severe sleep deprivation. It's a person who sees the importance of language and truth, who's aware of the tools at his disposal and uses them to the full of its extent. Ofcourse the language in question is, altough vital, not the main issue. The problem lies with the attitude of the programmer and (the lack of) his pursuit of excellence.
Despite your claims I wouldn't value natural language all that high. It certainly is valuable in its own way (obviously I'm talking about the field of CS here, no one doubts the importance of natural language in every-day conversation) but mainly in order for one to notice the intricate intricacy, the paradox and the things unsaid, yet assumed nonetheless. It makes one value formal language even more and allows one to accept that computing science is distinct from everyday life and thus shouldn't be treated like it.
While this was certainly true in the early days of StackOverflow, what I've found recently is that taking care and time to craft a well worded response actually has a tax associated with it. And, that tax is not being the first to answer the question. This usually causes "that's a duplicate answer" type finger pointing and can be harmful to your reputation.
So, while I agree that initiallly what Jeff is saying was true, these days it's more like a game show. The first to hit the "buzzer" wins.
I disagree on one point - you need more than a modicum of technical skill. There is a lot of well-commented bloatware, atrocious API designs which are meticulously documented, and even simple things like which parameters or when to split something into a set of functions that are badly messed up or never refactored.
Using a very fine typeface and perfectly formatting "Jabberwocky" doesn't make it clear and transparent.
In some ways too much skill can be a problem (which is why C is great and terrible at the same time). If you are really skilled, you can actually write usable bloatware in the atrocious API as a monolith or as tiny fragments, but the higher skill is in knowing how to reduce the design and architecture so that you only need to be a mediocre programmer to implement it.
At that point, being able to communicate it effectively is a big bonus (especially the hows and whys), but I find either I can read the code (sans comments!) and from its existing topology and structure I can understand it, or it is an impenetrable gordian knot that no amount of gloss will reveal even if the translation into the colloquial speech is both credible and accurate. The medium is first and foremost the code itself. If that is bad, being able to explain it instead of fix it is not a plus.
Let me preface this comment by saying that I do blog, often, about software engineering.
I think a lot of the problems that people have in writing a software engineering blog is that a lot of the time it feels like blasting a shotgun into the nether black. It's actually pretty hard to get people to read your blog so that you can start having a discussion with your audience. It's true that just writing your blog for your own benefit is a great idea for developing communication skills, but a feedback loop is definitely a step up. Stackoverflow is great for this reason, because when you ask your questions, or answer someone elses question, you have a feedback loop that will correct your aim each time, nearly always for the better.
What do you think is a good way to get the discussion started for those who have been writing software engineering blogs, but have no readership to build a dialog upon?
@ctrlShiftBryan and @Plasticsyntax
Maybe my communication skills need updating. I said this:
"It's far more important to write clear code, than to write code that needs to be explained by comments and external documents."
I've been doing this a long time now, and paying attention while I've done it. I don't really need to be reminded what comments and documentation are for ;-)
However, both of you have made comments that I might have made 15 or so years ago, when I had only been in the business a few years.
Over my 20+ years doing this job professionally, I have come to the realisation that code that needs very much in the way of comments and/or documentation (in the traditional sense, at least) is bad code. The fact that Joel makes remarks like the one quoted is one measure of his skill.
You may need comments in your code, but they should be very rare occurrences. You may need documentation, but if I have to read both your code and your documents to understand any given piece of code, it means I'm going to have to maintain both your code and your documents. This rarely works well, either as a means to understanding, or as a practical matter keeping everything in sync. You should strive to make as much documentation as possible unnecessary.
Your code is far more important that either comments or documents, because there is far more of it (I hope!!), and you spend far more time looking at it.
Try to write your code without the need for comments. A comment explaining a block of code almost always means there is a method waiting to be extracted. A comment explaining a function/parameter/variable usually means there is a better name waiting to be used.
Try to minimise the documents you need. Your code should explain nearly everything about itself. Try and limit documents to things outside of the code, like working environment setup, for example. Critique the documents you already have. Do they still reflect reality? When did anyone last use them? Are these documents helping you deliver great software, or are they an unnecessary burden slowing you down?
Writing tests before code will get you cleaner code. Then you'll find you won't need all those comments.
Gerald Weinberg made the same observation in his 1971 classic, The Psychology of Computer Programming, that the most important language for a programmer to know isn't a programming language at all, but English, as programming is primarily a social activity.
Great book, still highly relevant 40 years after it was written.
I entirely agree with this blog post. In fact it was Jeff's comments that got me started with my own blog ( http://www.matthewedmondson.info ). Communication is massively important in software development - after all if you can't communicate with other people how are you going to communicate with a computer?
I am not a programmer, so if you don't want to sully yourself with what non-programmers have to say, stop reading right now. I do love this blog, because a lot of it is transferable to non-programming situations.
My uncle worked for Amoco for thirty years. He had two bachelor's degrees, one in physics and one in chemistry, and he always said that the thing he did the most of in his career was write.
My mother taught Freshman English. Because she taught at a particular time, she always ended up with a lot of athletes in her classes, and after an assignment or two with students insisting that they didn't have to revise what they'd written, the following conversation would ensue:
Mom: "Would you ever go to your coach on Monday and say, 'Coach, I don't feel like practicing this week, just play me on Saturday'?"
Students: [horrified] "No!"
Mom: "Why not?"
Students: "Well, you *have* to practice, or you won't get any better!"
Mom: "Well, revising your writing--by doing multiple drafts, for example--is practicing your writing."
Her report that this Rubicon had been crossed was always a hoot around the dinner table. And most of the class then bought in to the "practicing your writing" concept.
You may be a programmer now -- but you may not always be a programmer. You may be responsible for mentoring new programmers, or teaching programming. You may be responsible for writing project proposals, RFPs, or final reports. You may move into management, and be responsible for writing about your subordinates', group's, or company's performance. You may (as someone noted above) have to explain to higher-ups what the heck you're doing, and why you need to do it. Or you may do something else entirely. Strong communication skills are always a huge asset, because lots of people don't have them...
Thanks, Jeff: I'll be checking out the writers site...
I've always enjoyed writing as much as I've enjoyed programming. I started a blog about a month or so ago at http://www.keyboardandchair.com . I really don't know jack sh*t about blogging, but I'm having a lot of fun doing it. I'm not sure if my theme of offensive and insulting tutorials will gain many readers, however. Either way I still laugh my ass off while writing them.
It is not about everyone person reading every single thing you post, but about the time when someone does finally read something you post, it being understandable enough that the point comes across.
Kind of like the newspaper intern who puts quality after quality into his work, only to have it overlooked time and time again.. Eventually, when it is not overlooked and given a chance, won't the hard work shine through then?
My other examples include references to The Day After Tomorrow, The Little Train That Could, and the beginnings of the internet :)
Let me just add that this is another area where the socializing affects of the Internet and digital age are a myth. Oh sure, you might have hundreds of Twitter followers and be an voracious texter, but that's not really, thoroughly communicating. 140 characters is to communicating what the appetizer course at a fancy restaurant is to the main course - it's not really food. Oh it's pretty - and pricey - but it's not substantive.
Just as you said, I've found that blogging has given me an excellent opportunity to hone and showcase my writing skills. And it's not just about being able to craft grammatically-correct sentences or even complex paragraphs. No, it's about developing a style of writing that gets your point across, sure, but perhaps more importantly, it maybe even gives the reader some sense about who you are.
Sadly, as others have said, blogging can often feel futile. And this is where being a good "netizen" comes in - you have a responsibility to nurture your fellow man's efforts by commenting on blogs. Sure, blogging should be it's own reward, creative outlet and all, but even the most stalwart writer still needs occasional validation, some kind of feedback - be it good or bad - that let's him know that his words are being read and might have some meaning to someone else.
From what I understand Jeff has not had a proper job in the area since 2008 ?
I remember when this blog used to be about programming, complete with actual code samples instead of opinions, I'm not really sure what it is about now, writing ?
I see your point. But I disagree on some of your points, especially the following:
You may need comments in your code, but they should be very rare occurrences. You may need documentation, but if I have to read both your code and your documents to understand any given piece of code, it means I'm going to have to maintain both your code and your documents. This rarely works well, either as a means to understanding, or as a practical matter keeping everything in sync. You should strive to make as much documentation as possible unnecessary. - Jim Cooper
Comments and documentation should not be rare or unnecessary. They should be common and necessary. Do you expect every programmer to understand the code you've written without checking any documentation? The purpose of comments and documentation is to give you first the whole picture. The code is there for the details.
Maintaining code that has no documentation is far difficult than code with documentation. If code and documentation aren't necessary, why do these popular frameworks (for example frameworks for Java) have to write documentation? If people are smart enough, these developers don't even need to put a special site detailing instructions or FAQs or even docs for their frameworks. All they need to do is post the zip file, and they should be done.
But you see a lot of people are thanking these people for writing documentation. They appreciate it. Then it means something. It means it helps them. Why would you deprive your fellow programmer of something that can greatly help him in his understanding? Is there anything wrong with that. I rather do extra work documenting than allow my fellow programmer struggle. After all, I'm a programmer. I know how difficult it is to maintain code that has no documentation. Believe me I had handled a big chunk of framework that doesn't even have documentation.
"Over the last 6 years, I've come to believe deeply in the idea that that becoming a great programmer has very little to do with programming. Yes, it takes a modicum of technical skill and dogged persistence, absolutely. But even more than that, it takes serious communication skills: "
.. and so you and joel decided to re-invent usenet really badly throwing away all the things that were learnt by hundreds of people about how client interfaces should operate in such environments.
I stand by my remarks. In particular:
Do you expect every programmer to understand the code you've written without checking any documentation?
Yes, almost all of the time I do. You may need to understand the problem domain (with or without documentation), but the code should stand alone nearly all the time. If it doesn't then it's bad code.
The purpose of comments and documentation is to give you first the whole picture. The code is there for the details.
Like I said earlier, I've been in this business a long time. I understand what comments and documentation are for. But I'll say it again, my experience over 20+ years leads me to my opinion that comments and documentation do not make up for bad code. Good code, almost by definition, requires little of either.
Maintaining code that has no documentation is far difficult than code with documentation.
Not necessarily true. Documentation needs to be maintained along with the code (misleading documentation is worse than useless). That's more work. Forever. For everybody who works on that code. So you should keep documentation to a minimum. This may or may not be zero, but if you can make your code understandable without documentation, that's just got to be better. Most of the time that's possible.
FWIW, the best code I've ever seen had no documentation at all (it had unit tests, which do the job better if done well).
If code and documentation aren't necessary, why do these popular frameworks (for example frameworks for Java) have to write documentation?
I assume you mean comments and documentation, and I didn't say they weren't necessary. However, good frameworks require less documentation. If you have a framework that requires a lot of docs to be understood, I'll argue you don't have a well written framework.
I would point out that writing frameworks (ie code that is intended to be widely reused) is much more difficult than "normal" code. Which is why so few of them are very well written :-)
Note that useful != well written.
Believe me I had handled a big chunk of framework that doesn't even have documentation
I've handled a lot of code too, framework and otherwise, over the last 20 some years of professional programming. I'm speaking from that level of experience. You don't fix crappy code with comments and documentation, you need to fix the code. My experience also very strongly correlates lots of comments with very poor code.
I rather do extra work documenting than allow my fellow programmer struggle.
If I was your fellow programmer, I'd rather you did extra work improving your code so you didn't need to document it :-)
Once upon a time, I thought as you did. Way back then, I was told that good code required comments only rarely. I didn't believe it either :-)
Maybe there is no point giving people the benefit of your experience, and you have to learn some things the hard way. But I urge you to do a bit of research and give writing code that doesn't require comments and docs a try.
Love this post.
Damn people really don't like documenting their code huh? If anyone ever tells you 'you don't need to communicate well to become a great programmer' my only advice is... 'just smile and wave'.
Congratulations for the content of your blog, which incidentally is very interesting to see.
voyance , horoscope 2011
Honestly this is exactly what i wanna hear always, since i am tying to trick myself be writing out micro-posts using twitter, emails and rarely blog posts. I liked the idea and the article, and as i am a technical community member i ll share this across community. Thanks again for the motivation
You just inspired me a lot. Thank you.
for the great article. I like your post I'll surely be peeping into it again soon!
I completely agree with this post and what a relief it is to read it from another programmer. I used to teach writing while in grad school and I often had Comp Sci students who were forced to take my class as part of their core requirements tell me how they didn't belong in a writing class.
Why not? I would ask.
Because we're computer science majors. We don't need writing skills.
Anyway, I'm a programmer and a writer and I have to say that in ADDITION to good communication skills (gone are the days where the 22 year old "genius" who can't make eye contact and speaks only in code is considered valuable), close reading skills are a must. Let's face it. Programmers have to do a LOT of close, careful reading in order to learn. I don't know about you, but I do read a lot of programming books and I expect the same is true of those I work with. And I'm pretty sure that skim reading documentation isn't the best way to learn.
Crown-Sat is a China based professional hi-tech company engaged in R&D, production and distribution of consumer electronics products, such as automotive, office and daily using electronics. As one of the best manufacturer and wholesaler in Shenzhen, we had good relationship with our customers all over the world. With the faith of “making friends before doing business”, we had almost exported our goods to the overseas market such as USA, Mexico, Germany, France, UK, Spain, Portugal, Sweden, Russia, Japan, Singapore, Malaysia etc.
"High Quality, Competitive Price, On-Time Delivery, and Good After-Sale Service" are our principle. We have received good reputation and support from our customers, promoting our development in these fields as well. Up to now, we have provided a large quantity of digital products such as the DVB, mini projector, solar related and cartronics, and the most hot sell products are Openbox S9 HD PVR,SkyBox S9 HD PVR ,Dreambox DM500 HD,
is it harry tuttle or henry tuttle?? HARRY TUTTLE OR HENRY TUTTLE?!! I'm not being kept up at night, but the internet doesn't know either. Buttle indeed! The Hush-a-Phone page on Wiki says Harry and DeNiro's character is Harry. But Wiki pages are about as concrete as the data it stands on, and just think it'd be so funny to have the Buttle/Tuttle joke backed up with the name being a little off too (jab at the Hush-a-Phone quality of service). Wondering if you might actually know? (it says in the top quotation both versions..... it's harry isn't it