Why do some people like programming?

Answer by Marcus Geduld:

- I like creating something out of nothing. That's not literally what you do when you're programming, because there's existing hardware and software that serves as a foundation for your work, but it sure feels that way. Someone has an idea and you build it from the ground up. When you begin, there's just an empty text editor. When you're done, there's a (hopefully) working program.

- I like building things people use. It's amazing to type up some code, press a button, and suddenly thousands of people on the Internet are playing with it.

- I like playing God. Programming allows you to build little worlds and then play with them, making adjustments and watching the effects. It's like owning a toy planet and saying, "I'm going to make it rain, today. Oh, look! All the little people have opened umbrellas!" This playing-God aspect of programming makes it similar to writing novels, painting paintings, or directing plays.

- I like working within systems that demand precision. This is exactly what some people hate about programming, but it thrills me. A misplaced semicolon or the smallest typo can be disastrous. This keeps me on my toes. It's like being the butler on "Downton Abbey" or "Upstairs, Downstairs." Everything must be just so. Some people like precision; others like being about to say, "I can't describe it, but you know what I mean..." I'm the former type.

- I like solving puzzles. If you want to see if programming is for you, try out this puzzle book: The Little Schemer - 4th Edition: Daniel P. Friedman, Matthias Felleisen, Duane Bibby, Gerald J. Sussman: 9780262560993: Amazon.com: Books

- I like research. Programming tends to involve much googling and reading through documentation.

- I like experimenting. There's a large component of trial-and-error.

- I like writing poetry, which is very similar to programming. Both the poet and the programmer are obsessed with words, obsessed with formal rules, obsessed with seeing how far they can push those rules, and obsessed with expressiveness. Programmers often talk about how expressive a particular programming language is. They mean something very similar to what a poet means when he tries to come up with expressive wording.

Both poetry and code can be exquisitely beautiful -- and in very similar ways. People are often surprised that I'm a programmer who also directs Shakespeare plays, but I've met lots of programmers who are into Shakespeare, crossword puzzles, scrabble, and so on. Joshua Engel is another Quora user who writes code and directs Shakespeare plays.

- I like communicating. Most good programmers will tell you that code is first-and-foremost meant to be read by people -- even to the extent that we'll sometimes write it in a way that is inefficient but easy-to-read.

- "There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton. I love the hard work of "naming things." Programmers generally have to come up with short words or phrases that label parts of the systems they're writing. It's crucial that these names be clear and apt.

Why? Because if you name something cButton, the next guy who has to work on your code may be befuddled. If you'd called it closeButton, he would have instantly known what you were referring to. Sometimes "he" is me a few weeks (or a year) later, when I'm reading my own code. It's embarrassing to come across cButton and think, "What did I mean by that?"

Last week, I was modifying someone else's code. It was for as web page with sections. Each section had a logo at the top. The original programmer had referred to those logos internally as "headers," e.g. "header1" and "header2." I didn't notice that, and so I named something within one of the sections "header." When I later looked over the code, I got totally confused between his headers and mine.

Then I thought it over and realized that his "headers" were always graphical logos and mine were text. So I renamed his "logo1" and "logo2" and mine "title."

This is just one small example of the sort of naming issues that constantly crop up. You either enjoy this sort of thing or you don't. I do.

- I like learning. Like sharks, programmers die if they stop moving. Because technology changes so fast, being a programmer means that "school" never stops. Even though I've been coding for years, I must constantly read programming books, follow blogs, and so on. There's no coasting!

I got into the game as a Flash programmer, which was lucrative for about ten years. Now Flash seems to be on its way out, so it's back to the books! But even while I was mostly coding Actionscript (Flash's language), I needed constant training, because that language went through many versions, some as different from each other as Spanish is from Portuguese.

There are many good programming books and courses, but you can't really learn to code by instruction. That will get you started, but they only real way to learn is to write code, fail, analyse the failure, and learn from it. So you must enjoy being an autodidact. I do.

- I like being a detective. Maybe 60% of programming is debugging -- figuring out how something works. That often means a ton of sleuth work. Sometimes you have to pick and entire program apart and put it back together again.

- I like solitary work. Programming allows me to do lots of that.

- I like collaborating. Nowadays, Few programmers work completely alone. Most are part of a team, and they spend part of the week doing close work with others and part in isolation. I feel a strong need for both sorts of work, and I like alternating between the two.
View Answer on Quora

 30 years of K&R is being celebrated.

Image

30 years of K&R is being celebrated.

This is an important book our life time and Inform IT has an article on "Leading Programmers Remember the Impact of The C Programming Language"

Roughly around 10 years ago to get myself into Software Development, I started solving all the problems at the end of the K&R book and bootstrapped my Project Uthcode for the third time.  I can safely say that it turned out be successful and I owe greatly to this one book.

Later when I started contributing to Python, I focussed mostly on Python and standard library which is written in Python.  Noticing how other programmers went about with CPython core, I wanted to re-read it to get into K&R get into implementation and design. That has not happened yet, but I am planning for it sometime soonish. I can get back and rely on K&R, plus I will have my experience to draw upon.

The Incredibles - Monalisa using rect and fills

Every once in a while you come across some amazing and something insanely creative by unknown folks in the internet. I have decided to capture those moments by title "The Incredibles" series.

Today, it happened to me. After doing a basic drawing tutorial at Khan Academy I saw a spin off program which I thought is a image loaded. I wondered why some one spun off a simple drawing tutorial and then loaded image for practice. But I was wrong. This whole image was drawn using rects and fill.

See it for yourself. The Incredibles super hero of this creation is to Mr. Peter Collingridge

Monalisa

Mona Lisa

Made using: Khan Academy Computer Science.

“If a thing is ...

“If a thing is worth doing, it is worth doing badly." - G.K. Chesterton

This is amazing quote, quite a guiding principle that many of us forget in our rapid pace of life. More so, it is so easy to mis-interpret it.  We live in a world that people demand perfectionism, mostly from others and every hides what they do for themselves.  This is where this quote comes in handy to remember. 

It is brilliantly explained in this article giving the context of this quote. Here is the section from the article which goes to the crux of this.

As for “the rearing of the young,” which is the education of the very young, this is a job not for the specialist or the professional, but for the “generalist” and the amateur. In other words, for the mother, who Chesterton argues is “broad” where men are “narrow.” In What’s Wrong with the World, Chesterton forsaw the dilemma of daycare and the working mother, that children would end up being raised by “professionals” rather than by “amateurs.” And here we must understand “amateur” in its truest and most literal meaning. An amateur is someone who does something out of love, not for money. She does what she does not because she is going to be paid for her services and not because she is the most highly skilled, but because she wants to do it. And she does “the things worth doing,” which are the things closest and most sacred to all of humanity – nurturing a baby, teaching a child the first things, and, in fact, all things.

The line, “if a thing is worth doing, it is worth doing badly,” is not an excuse for poor efforts. It is perhaps an excuse for poor results. But our society is plagued by wanting good results with no efforts (or rather, with someone else’s efforts). We hire someone else to work for us, to play for us (that is, to entertain us), to think for us, and to raise our children for us. We have left “the things worth doing” to others, on the poor excuse that others might be able to do them better.

 

Meeting with Bram Cohen

During PyCon Sprints, I met Bram Cohen who had come down to talk to Guido and have a word on networking protocol world. It was interesting to see two experts talking. Later I invited Bram to give a tech talk at Twitter. Bram gladly accepted it and came to Twitter office to talk to us about his latest invention http://live.bittorrent.com He had been working on Distributed Live Streaming for few years and thought it was a hard problem to solve. He could dedicate himself to it and came out with live.bittorrent.com - Using this anyone can live stream a video. You can become a live video publisher too and people all around the word can see your channel in real time. This is a huge break through. My experience at Akamai helps me realize the kind of break through this can bring to real time live streaming.

Bram went with the technical aspects of the design of the live bittorrent technology and how to keep the delays as minimum as possible. He was talking at the network packets level and explaining how the packets need to be distributed from one node to another so that delay can be as minimum as possible and what are the bottlenecks that exist during the packet transfer. The innovative solutions that he had use to make these possible. He started by giving a pitch to Dan Bernstein's ciphers and explained about the TCP handshake and udp transfers and how uTP goes in the background during transfers and not affect peak real time traffic. The details could by got only if I read through his spec a couple of times.

One interesting thing that struck me was. One engineer asked the question, "how did he test his development of live bittorrent system?". Bram got excited to share his valuable experience in doing that. He said, few years ago he made a point saying "Remove all psychic powers in software development" - by this he meant, remove all assumptions that a software will work "magically", "assume" that it work under all conditions, but rather encode the scenarios and simulate all the possible scenarios under which you want your software to work and then run your software through it. To this effect, he seemed to built a small simulator which can help him test the system. That was a good learning and major take away for me from this session.

Book Review - The Startup of You

The Start-up of You: Adapt to the Future, Invest in Yourself, and Transform Your CareerThe Start-up of You: Adapt to the Future, Invest in Yourself, and Transform Your Career by Reid Hoffman

My rating: 4 of 5 stars

This book is from the CEO / Co-Founder of a Web 2.0 company, LinkedIn and goes a great detail into the culture and professional aspects of similar companies that existing in silicon valley. Reid Hoffman gives the examples of many startup founders and sets the stage for how and why started their respective ventures. The stories which I did not know earlier and which caught my attention were the stories of Netflix and Zappos. Both were amazing. The best part the book in my opinion is the many examples that Reid and Ben provide as examples to support the point they were trying to say.
I also liked the chapters in which the authors give sufficient focus on the failed auto industry business in US and what the computer industry and the leaders of computer industry can learn from that episode.

Most part of the book is no-frills, bare minimum good practical advise which many should follow and I believe, it is obvious to everyone. But reinforcing and giving concrete shape to those abstract ideas still helps and this book does a great job at it. Since I am enthusiastic about startup and their stories, I found this book easy to read, it caught my attention quickly and I could finish it without any lag. The final list of the reference books many a good one to follow up and keep the interest in the subject going. This book is about Internet business and your career when the Internet is always ON. I would say it should be categorized under "popular-business" similar to "popular-science" genre.



View all my reviews