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.
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 ;-)
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.
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 ;-)
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.
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.
> Co-workers and bosses are not usually your friends
I second that unfortunately. :( The flipside of that though is that you probably won't be their friend either, even if you'd like to think of yourself as a good person.
After getting burnt by fake friends at work, I went for years without putting personal items into my cube because I wanted to ensure that I always remembered this. Nowadays I think that was the wrong thing to do though. It is not worth living so much of your life in an environment that you can't turn at least partly into your home for several hours a day. Just realize that home is temporary, well- unless you work at home.
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. )
Some of us enjoy or have enjoyed documentation, process, management and that isn't mentioned. Some perfectly successful programmers love QA, etc. A lot of them have already made that career choice and may be perfectly happy. You can't have an outstanding restaurant without great people in every position- wait staff, dishwasher, chef, etc. and similarly, everyone is required for a successful project, and successful projects can make people successful.
I do agree with trying to determine what you like doing early on, however employers lie during interviews. I wanted to go the middle-tier service track and was promised that, but instead got put into an IT and web app development job that periodically involves a service to be developed or used. Instead, try not to be a part of a company that you feel you are more than adequate for during the interview and whose overall mission does not prominently include what you are interested in.
And the absolute worst thing that can happen to a developer regardless of aspiration is to be golden-handcuffed to job where they atrophy. You can easily fall into such a trap.
Your family is and always shall be the most important thing that happens to reside in this sometimes wonderful sometimes terrible world. Do what you love and take care of them and others. That is all you can do. Everything else is temporary.
Lastly, don't fear- just do. Be what you are, and what you are will change.
*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.
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)
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.
26 comments
[ 3.1 ms ] story [ 73.3 ms ] threadOf course, now I'm not in a programming job, so I can only imagine I've gotten worse.
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 ;-)
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.
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 ;-)
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 second that unfortunately. :( The flipside of that though is that you probably won't be their friend either, even if you'd like to think of yourself as a good person.
After getting burnt by fake friends at work, I went for years without putting personal items into my cube because I wanted to ensure that I always remembered this. Nowadays I think that was the wrong thing to do though. It is not worth living so much of your life in an environment that you can't turn at least partly into your home for several hours a day. Just realize that home is temporary, well- unless you work at home.
Some of us enjoy or have enjoyed documentation, process, management and that isn't mentioned. Some perfectly successful programmers love QA, etc. A lot of them have already made that career choice and may be perfectly happy. You can't have an outstanding restaurant without great people in every position- wait staff, dishwasher, chef, etc. and similarly, everyone is required for a successful project, and successful projects can make people successful.
I do agree with trying to determine what you like doing early on, however employers lie during interviews. I wanted to go the middle-tier service track and was promised that, but instead got put into an IT and web app development job that periodically involves a service to be developed or used. Instead, try not to be a part of a company that you feel you are more than adequate for during the interview and whose overall mission does not prominently include what you are interested in.
And the absolute worst thing that can happen to a developer regardless of aspiration is to be golden-handcuffed to job where they atrophy. You can easily fall into such a trap.
Your family is and always shall be the most important thing that happens to reside in this sometimes wonderful sometimes terrible world. Do what you love and take care of them and others. That is all you can do. Everything else is temporary.
Lastly, don't fear- just do. Be what you are, and what you are will change.
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.
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.
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!
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.
Followed by
Goranka Bjedov is a capacity engineer
Hmm.