Tips to succeed as a programmer (Facebook engineering Notes) (opens in new tab)

Well, OPC (Other People's Code) is generally unpleasant to read. ;) Rarely do people try to write programs "for people to read, and only incidentally for machines to execute", as SICP puts it.

So, I think it helps to do more than just passively "read" it. I might create a private branch, run the sucker with lots of print statements, comment the hell out of it, take copious notes in org-mode, draw diagrams to leverage my visual systems, etc. (It might feel silly, but no one's watching.)

Running it repeatedly (with print statements) allows me to form little hypotheses and test them. The idea is to approximate having a REPL. Something like emacs helps to automate this as much as feasible.

It's really about practice and context.

Context makes it so much easier. In the real world there is usually a purpose to code, and good code has a cohesive metaphor you can understand before you start reading. Practice eventually makes the syntax second-nature, but I found being able to understand the context and subtext of the code is a much bigger boost.

I took a poetry class in college and found that learning to read poetry helped me become more fluent at reading code. Instead of reading it like prose, from start to finish, reading poetry is about building a mental castle of what the poet is talking about, and then the actual words fill in the important details. Plus you learn to pick up on repetition, rhythm, deviations from established patterns and is-a relationships ;-)

At least you understand how important it is. I graduated from engineering school in 1999 and I still marvel at the classmate in my data structures class who complained that there were too many code reading exercises on the exams during the semester-end course evaluation. It was like he thought he would spend his life writing code and never reading it, I was amazed.

I recently started programming at work after at least a decade of mostly not programming at work. My experience so far has been that reading code is easier than writing it, at least when an unfamiliar SDK is involved.

For me it's the other way around. Reading and understanding others code is easier for me rather developing it from scratch in the beginning. Though now i have improved in the later part.

Patio is a successful "small tech consultant", and enjoys blogging and sales and marketing. Some people prefer to lean more heavily/exclusively to technology and math, and they are needed and well rewarded to work on large technical systems. (My team is hiring. )

I had the same thoughts as I was reading this... why limit yourself to success as a programmer? Why not success as a problem solver?

This sounds similar to the edw519 approach of "talk to people, see how you can improve things."

I think there's a lot to be said for it. I suspect we (as a species) waste a lot of time because we're ignorant of the big picture.

I had to hit refresh a few times to get a page that loaded

works for me