Live data from Hacker News

How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

samizdat.mines.edu

21–30 of 49 posts

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#21
"Programming languages should really be called notations in that learning one is not at all as difficult as learning a natural language."

Brilliant! This whole section on choosing a language is great.

"One tends to think of a large system that has components in three or four languages as a messy hodgepodge; but I argue that such a system is in many cases stronger than a one-language system..."

This part sounds insane until you start working with eventually consistent messaging like: http://www.reactivemanifesto.org

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#22

>>But it is really child's play compared to everything else >>that a good programmer must do to make a software system >>that succeeds for both the customer and myriad colleagues >>for whom she is partially responsible. Why the use of the word "she" ? I see a lot of articles written where the undefined person will be a she. I speak french, and "person" is a feminine name, so you can say about a person "she", but why…

why not?

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#23

>>But it is really child's play compared to everything else >>that a good programmer must do to make a software system >>that succeeds for both the customer and myriad colleagues >>for whom she is partially responsible. Why the use of the word "she" ? I see a lot of articles written where the undefined person will be a she. I speak french, and "person" is a feminine name, so you can say about a person "she", but why…

Don't hate...

It's a simple method to get people thinking about issues :)

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#24

>>But it is really child's play compared to everything else >>that a good programmer must do to make a software system >>that succeeds for both the customer and myriad colleagues >>for whom she is partially responsible. Why the use of the word "she" ? I see a lot of articles written where the undefined person will be a she. I speak french, and "person" is a feminine name, so you can say about a person "she", but why…

why not?

It's unconventional, and hence distracting. It's a mental bump, it gets you thinking "why so?" instead of focusing on the text. Pretty much the same problem as violating coding convention in source code.

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#25
post #19

What is wrong with us in this sick, perverted, twisted, dying and rotting industry? If you encounter these problems, start applying to a new position. Don't deal with management; don't "educate" them. Don't fix the organization you've tricked yourself into joining. Just polish your resume and leave. It seems like we're an industry that defines Stockholm Syndrome.

Sick, perverted, twisted, dying and rotting industry? Wow, you can't have had many jobs. Our industry is like heaven in comparison to the really rotten and twisted ones.

Depends where you live. In Silicon Valley programmers are treated well as human beings. In others, programmers are treated as bottom of barrel employees, like short order cooks to implement somebody elses vision, and their input not valued.

I've seen quite a few programmers have breakdowns, and have to leave the industry. Far higher rate than other industries. I think it's because programmers see themselves as creatives, but managers in some companies seem them as builders of somebody else's vision.

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#26
post #23

>>But it is really child's play compared to everything else >>that a good programmer must do to make a software system >>that succeeds for both the customer and myriad colleagues >>for whom she is partially responsible. Why the use of the word "she" ? I see a lot of articles written where the undefined person will be a she. I speak french, and "person" is a feminine name, so you can say about a person "she", but why…

Don't hate... It's a simple method to get people thinking about issues :)

But this text is not about these issues

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#27

>>But it is really child's play compared to everything else >>that a good programmer must do to make a software system >>that succeeds for both the customer and myriad colleagues >>for whom she is partially responsible. Why the use of the word "she" ? I see a lot of articles written where the undefined person will be a she. I speak french, and "person" is a feminine name, so you can say about a person "she", but why…

It's not about political correctness. The writer wanted to use 'she' so the writer used 'she'. Those words are interchangeable.

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#28
post #24

Earlier quoted context omitted.

why not?

It's unconventional, and hence distracting. It's a mental bump, it gets you thinking "why so?" instead of focusing on the text. Pretty much the same problem as violating coding convention in source code.

Human language is and will always be much more forgiving than coding conventions in source code. It wasn't distracting for me and it is fairly conventional now to use he and she interchangeably. Conventions change in language.

Re: How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002)

#29

What is wrong with us in this sick, perverted, twisted, dying and rotting industry? If you encounter these problems, start applying to a new position. Don't deal with management; don't "educate" them. Don't fix the organization you've tricked yourself into joining. Just polish your resume and leave. It seems like we're an industry that defines Stockholm Syndrome.

I read this article completely differently. It's not saying that you should try to fix a dysfunctional organization. It's telling you how to succeed in whatever organization you decide to stay in. And it is telling you how to maintain and improve the health of an already healthy organization.

I have had the privilege to work mostly in happy, stable companies, and all the team and organization suggestions in this article have been helpful to me. The "how to get promoted", too. I'm now in a position to do even more to make my team healthy and my company successful. And I love it.

Edit: we're not in the Valley. We're in the DC area, which generally has fairly poor working conditions and long hours for programmers. It helps that we're a product company and not a bodyshop.

Post reply on HN