Thoughts on being a programmer

http://www.yelsew.com/thoughts.html

by earnubs • 14 years ago

235 190 14 years ago

tokenizer2• 14 years ago

Be yourself. Code for fun. There's hundreds of ways to write the same thing, don't be a dick about your way, but stand up for good practices. Respect those who accomplish great things, because it was a lot of work, even if they say it was a weekend practice, they took a lot of time to get to that point. If you code correctly, one line changes are possible. Learn to desire success more than you fear failure. (I like this one) Don't become the old people you hate, always try to learn new things, no matter how alien. Who cares if you're coding on production live? Right? Right? Comments are for the weak, tracing and prototyping code is not. Mistakes are inevitable *It's hard being the smartest person in the room sometimes, wear it with humility rather than pride.

My version of the list. This was fun!

nickolai2• 14 years ago

>Comments are for the weak,

Care to elaborate on this ? Commenting code is bad ? Or did I miss the irony ?

recycleme2• 14 years ago

I've met a few senior level programmers who frown on detailed commenting (or commenting at all). I cannot wrap my head around this since I consider it best practice to comment.

A reason given to me was that "it takes up too much time to comment and when you make a code change you need to make a change in the comments as well." To that I say, so what! I would like the future me (or the future programmer) to have full knowledge on what's going on in the code.

sunwooz• 14 years ago

Maybe he's saying, if your code is simple and elegant enough you won't need to comment.

anusinha• 14 years ago

A bad comment can waste a lot more time than the absence of a comment or a useless one (like x += n; //add n to x).

le-manchester2• 14 years ago

>Don't become the old people you hate, always try to learn new things, no matter how alien. So following that: There's a good talk about Code Documentation: http://www.youtube.com/watch?v=tCw7CpRvYOE

FuzzyDunlop• 14 years ago

I think it could be summarised as thus, in general terms:

You should never need to write a comment to explain what you're doing. If you feel you have to, rewrite the code until it doesn't need explaining in a comment.

    # this method manipulates dimensions
    def method_x(a, b, c, d)
      # a is the width
      # b is the height
      # c is the depth
      # d is a list of options
      ...
    end

That could obviously be re-written as:

    def manipulate_dimensions(width, height, depth, options)
      ...
    end

However, it may very well be the case you have to explain why some code exists, or why it wasn't done another way:

    def post_to_awkward_api(data)
      # stupid.io doesn't accept HTTP Post params
      # so we have to use a comma separated string
      silly_string = data.join(',')
      ....
    end

    def bug_fix_workaround
      # see http://stackoverflow.com/relevant-question/...
    end

Not that my examples are amazing. But there'll always be the case where another developer (or even yourself) is not privy to the thought process that conceived a particular block of code.

donall• 14 years ago

There's a lot of back-and-forth in this discussion already and I feel like some people aren't understanding that it's not about _never_ commenting the code; it's about only commenting when it is absolutely necessary (which is actually quite rare if you're writing clean, simple code (which is, itself, quite rare!)).

I think that everybody should be required to read the chapter about commenting in "Clean Code" before contributing to this discussion. It's very java-centric and not perfect, but there is some really good insight. There is a pdf available here: http://www.tud.ttu.ee/material/kallik/JOOP/Clean_Code_-_A_Ha... (if it really helps you, consider buying a copy and supporting the authors).

overgryphon2• 14 years ago

Don't hate the old people. They have a lot to teach.

tokenizer2• 14 years ago

You're right. I guess I meant the aspect of fear one has of new things as they get older. I hate that personality trait. It is more prominent in older people.

clwoodson• 14 years ago

What others have said. Good code is self commenting. I prefer to see comments reserved for instances where its not clearly obvious why a piece of code exists (hacky workarounds, etc...)

norswap• 14 years ago

Work on unimportant problems. http://www.yosefk.com/blog/work-on-unimportant-problems.html

recycleme2• 14 years ago

Communicate often. Have a beer with a fellow programmer. Don't be afraid to break code.

sukuriant• 14 years ago

> Don't be afraid to break code.

Just not in production :)

bbwharris• 14 years ago

There's no better way to learn.

codegeek2• 14 years ago

Problem is that code always breaks in production. What we should strive for is not to cause a critical break that creates massive loss for the company. But code has and will break in production.

tene• 14 years ago

Even better is to have an automated immune system that detects production issues and rolls back. We push to production dozens of times a day with dozens of engineers committing, and with that environment, problems will eventually slip through your local tests and buildbot.

Bugs happen; it's far better to focus on robustly dealing with problems than it is to build layers of bureaucracy and process in an attempt to pretend that you can avoid all errors. At my current company, dozens of engineers are pushing to production dozens of times a day. We have an extensive test suite that runs on every commit before code can be pushed to production, but there's always something that slips through, which is why we also have an automated cluster immune system that can automate a rollback whenever any metrics go bad during or after a push.

Bugs happen; life is better if you expect it and plan for it. My philosophy is, break production, and keep breaking it until you're damn good at dealing with production failures. Don't let fear of breaking production slow you down.

3am_hackernews• 14 years ago

It is written so beautifully that the "code" part of these thoughts can be substituted for many other things: design, engineering, life etc.

jawr2• 14 years ago

>Always back up before tidying up. I liked this piece of advice, it's a lesson we all hate to learn.

arscan• 14 years ago

Happened to me last night -- I wish I read this yesterday. Who am I kidding... I prefer to learn these lessons the hard way :)

Ralith4• 14 years ago

Don't you use version control?

lazyjones• 14 years ago

I miss VMS, it solved this problem in such a naturally elegant way.

frou_dh• 14 years ago

Something in one of Zed Shaw's old talks stuck with me. Roughly:

"Don't go with the flow of the industry. Try [unconventional] things because there's something beneath [software] that we haven't figured out yet."

I suppose there's two personal disclaimers:

- I'm not that interested in the business aspect of software.

- The answer to what the magic beneath is may elude me due to it simply being "math, stupid".

toomuchcoffee• 14 years ago

...due to it simply being "math, stupid".

Care to elaborate?

podperson2• 14 years ago

I liked "err vicariously" ;-)

It's good to learn from your own mistakes, and even better to learn from someone else's.

lobo_tuerto• 14 years ago

Yeah, but sometimes "vicariously" doesn't cut it, you have to "do the work," you have to grind it out.

http://raganwald.posterous.com/what-ive-learned-about-learni...

podperson2• 14 years ago

Hey, it's a pithy one-liner (two-worder) -- and like any such chestnut is going to be wrong a lot of the time.

Even so, learning from someone else's mistakes is "cheaper" than making mistakes yourself. The further you can get by avoiding mistakes others have made so you can get to your own personal mistakes, the better.

I'd say "err vicariously" gets better the more you think about it, rather than needing to be nitpicked.

anthonyb3• 14 years ago

It's a maxim. It's supposed to guide your behaviour, not be taken 100% literally.

worldsayshi• 14 years ago

Yea. A good workplace is one in which calling "that one is my fault" is a natural part of your work flow and doesn't cost you points (unless you become to frequent).

alanmackenzie• 14 years ago

I would add: Don't release on a Friday.

gacba• 14 years ago

Sadly, the company I work for ONLY releases on Friday nights because the business closes out at 5pm. sigh

joe_bloggs• 14 years ago

"Err vicariously"

Loved that. Subtle, yet deep!

twakefield• 14 years ago

> There's always plenty of room for improvement - in your code, in your abilities, in you.

I just saw an amazing movie about a man that embodies this philosophy: "Jiro Dreams of Sushi"[1]. This man's dedication to further mastering his craft is unparalleled. Even though he is widely regarded as the best Sushi chef in the world, he is still singularly focused on becoming better every day.

I highly recommend watching - it's very inspiring.

[1] http://en.wikipedia.org/wiki/Jiro_Dreams_of_Sushi

joe_the_user• 14 years ago

Don't be an asshole

Agreed but on the page, it looks a bit of out of place with the other points.

My mind fills in the details as "don't act like you are the programmer who's a hundred times more productive than the others, even if it seems like you are".

But that's a big question. Apple Computer arguably expects its programmers to all be the x100 producers and was managed by someone who it more or less was admitted to be an asshole (a genius, inspiration, unique asshole but still an asshole).

So it think the greatness and asshole-dom question is not settled for people even if I would embrace it.

jebblue• 14 years ago

That was a short, concise, pragmatic, wise and rockin article.

einhverfr21• 14 years ago

The bit about there always being room for growth was driven home for me yesterday as I was looking through how to build an object model in PostgreSQL using object-relational features. I went through the features one by one and discovered that I had only scratched the surface of that aspect of PostgreSQL. I suddenly understood how to rethink what I was doing in terms of design patterns in order to build object interfaces in the db for the relational underpinnings.

Thoughts on being a programmer

Related Stories