Tips to succeed as a programmer (Facebook engineering Notes)(facebook.com)
facebook.com
Tips to succeed as a programmer (Facebook engineering Notes)
https://www.facebook.com/notes/facebook-engineering/three-tips-to-succeed-as-a-programmer/10150639100788920
26 comments
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 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.
Not only that, but you also strengthen the relationship and stay up-to-date (micro & macro).
In some cultures (eg. ex-communist countries) there is a natural "distance" (approachability) between employees and management. I did not see this in Western Europe (at least at such level)
EDIT: thanks for the tip about edw519 ( https://twitter.com/#!/edw519 ). New feed to read!
In some cultures (eg. ex-communist countries) there is a natural "distance" (approachability) between employees and management. I did not see this in Western Europe (at least at such level)
EDIT: thanks for the tip about edw519 ( https://twitter.com/#!/edw519 ). New feed to read!
Counterpoint: patio11's http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro....
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?
1. Look for jobs that will let you program. ... You want your job title to be ‘software developer,’ ‘software engineer,’ ‘programmer,’ ‘coder
Followed by
Goranka Bjedov is a capacity engineer
Hmm.
Followed by
Goranka Bjedov is a capacity engineer
Hmm.
I love how I can just read the bullet points and glean 90%-95% of what the post is about. So many blogs waste words.
Reading code always worried me. That was always my biggest deficit in school - I couldn't just pick up someone else's code and dive in, it took a lot of effort to understand anything more than the most basic code.
Of course, now I'm not in a programming job, so I can only imagine I've gotten worse.
Of course, now I'm not in a programming job, so I can only imagine I've gotten worse.
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.
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.
Don't add printf, add unit tests!
Printf tells you "this function entered, then that function" while the program is running. Unit tests are trendy, but how do you know what to unit test before you even know the code paths? Do you even care about individual functions at that level? Printf may be dirty, but in the initial stages it's better even than a debugger with breakpoints.
Interesting, I too kind of believe that print statements are better than debuggers, but I always thought that was an irrational belief on my part. (Like, I often don't have a decent debugger available, so never got much experience using them.) What are your reasons?
It's just easy, intuitive, doesn't require any scaffolding, and gives you just the information you want, exactly as your program sees it, yet with the full power of the language to format it exactly as you want to see it, in the most useful way. A breakpoint will do the same thing sure, but only by stopping your program in its tracks! Dtrace is the only thing I've seen that is as useful as liberally sprinkled printf's.
A unit test will tell you if you know what output a function should give for a given input, that it does. Ermm, brilliant, but what if that function isn't on your code path anyway? And assuming that you already understand the program well enough to create any state the function expects if it's impure. Above poster has drunk too much Kool-aid and is suffering from Golden Hammer Syndrome ;-)
A unit test will tell you if you know what output a function should give for a given input, that it does. Ermm, brilliant, but what if that function isn't on your code path anyway? And assuming that you already understand the program well enough to create any state the function expects if it's impure. Above poster has drunk too much Kool-aid and is suffering from Golden Hammer Syndrome ;-)
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 ;-)
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.
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.
in fact, these are valuable lessons for any position. Specially, the last one.
1. Look for jobs that will let you <do whatever you want to do>. 2. Don’t give up on becoming <whatever you want to become>. 3. Learn how to take charge of your career.
1. Look for jobs that will let you <do whatever you want to do>. 2. Don’t give up on becoming <whatever you want to become>. 3. Learn how to take charge of your career.
Crisp and to the point. Likes it.
The one thing to add (related to 1 and 3) is:
I once worked for a company where 1 week/month the managers would work in 1 department (as regular team members). With the hands-on feedback, they would improve the process/team/business. Needless to say, that company was making profits in the 2008-2009 "dark-age period".
The main lesson for me is that software is the business where you learn about & improve other businesses. The value is that you get to understand better the world (business) around you. That way you can avoid building "innovative products" that no one needs.