
Tips to succeed as a programmer (Facebook engineering Notes) - swapsmagic
https://www.facebook.com/notes/facebook-engineering/three-tips-to-succeed-as-a-programmer/10150639100788920
======
tdr
Timeless advice for any software engineer!

The one thing to add (related to 1 and 3) is:

    
    
         *do not focus completely on the technology. learn what's around it also*. 
    

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.

~~~
invalidOrTaken
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.

~~~
tdr
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!

------
JoachimSchipper
Counterpoint: patio11's [http://www.kalzumeus.com/2011/10/28/dont-call-
yourself-a-pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
programmer/).

~~~
Drbble
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. )

~~~
Estragon
As far as I can tell, you have provided no contact information at this stage,
so the information that you're hiring may not do anyone any good. :-)

~~~
Drbble
I am confident that you've heard of us and others like us, and know how to
apply.

------
gaius
_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.

------
jon6
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.

------
bsphil
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.

~~~
calibraxis
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.

~~~
Drbble
Don't add printf, add unit tests!

~~~
gaius
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.

~~~
calibraxis
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?

~~~
gaius
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 ;-)

------
brunohq
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.

------
denzil_correa
Crisp and to the point. Likes it.

------
perlpimp
404

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

