>>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 in English ? Especially when in male dominated jobs like programming. A programmer is likely to be a he than a she, so why try this hard to be politically correct.
"preferred (but not required)" is what wikipedia actually says, along with generic-he being the current usage (not rule).
Interestingly wikipedia also states "In the 19th century, grammarians in England petitioned the British Parliament to declare gender-indeterminate pronouns as 'he' rather than 'they', which was common usage at the time. "
The english language is far from a codified, logically consistent system.
It's not really any less correct than a genderless pronoun, even if one particular panel disagreed. I see no reason to use a masculine pronoun when a generic one will do, and could only call it "political correct nonsense" if an author insisted on either alternating between he and she, or used "he/she".
I find things written with lots of genderless pronouns can make the writing unclear. Lots of "They" , "Their" feels unnatural and clumsy when talking about people and it can become difficult to decipher which parts of the text are referring to a person and which to some inanimate thing.
Just as frustrating is writing that switches pronoun gender when referring to ostensibly the same person. However describing some operation between two people "Alice and Bob" it can improve clarity to make both people belong to different genders.
Every modern dictionary disagree. English usage of singular they dates back to 15th century still you assert it here without any argument.
Nothing wrong with asserting things if you do that with stuff disprovable by one dictionary/wikipedia search though you make not too bright impression to put it mildly.
As to using she it's very common convention these days in some domains. Many books on games use that for example (chess, bridge, go, poker - you need to a pronoun for black/white/last to act player there ). I also saw some computer science books using it. At this point I would say it's so common that it becomes part of the language. I personally like it although I can see how it raises eyebrows when encountered for the first time :)
You'll notice the same thing in the examples given in role playing game books. It's relatively common to use a female actor as an example, though I cannot remember why.
It's not a matter of being grammaticaly incorrect or correct, but rather to imply that for this example, the programmer is female. It's goal seems to be inclusion. The other reason is that perhaps that the programmer the author thought about when writing this is a lady.
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.
' she ' occurs a total of four times in the entire thing. If you're getting noticeably slowed down by these four mental bumps then perhaps it is more you and not the text.
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.
I don't get your point. Obviously if it's a really bad convention (naming all predicates '{something}Th1s1sAFuncT10nThatReturnsABooleanValueAndILikeCheese', say), it might be worth breaking, even if it's initially distracting. Presumably you want to be making the point that this is a convention that isn't worth breaking?
It is conventional to use "he" when you mean "someone" (regardless of the actual gender).
Of course you may argue that this convention is evil, as a product of political oppression etc. etc.
And I'm not even questioning that - my point is that this is beyond the point. Even if it's true, it doesn't mean it has to be brought up everywhere all the time.
I'd like to be able to read an article on programming (or any other neutral subject) without an unrelated political or social agenda being shoved in my face, in whatever form.
If somebody says "to hell with your pet peeves, this is more important and you're probably a bigot anyway", that's fine to me - it's a matter of taste.
It gets on my nerves more when people pretend not to get the point at all (for the sake of polemics of course). "The use of the word she? Why on Earth would you think it sticks out? Of course if one becomes a programmer, then as a programmer she bears certain responsibilities. I can't see what you mean? I'm stumped? Why can't you read on - you're stupid, huh?" (as aaren subtly hinted in reply to my previous comment)
What? It has to be brought up everywhere. That's the whole point behind trying to change usage: people are supposed to start doing it, and then it's likely to brought to your mind.
Unless your point is that you're tired of it coming out as an explicit point for discussion, as in this current thread of the conversation. That's optional to the core of the effort.
"It has to be brought up everywhere. That's the whole point behind trying to change usage"
It's not much of a point then ;)
If it even did some good to anyone. But all this linguistic ritual smells of magical thinking to me. The idea that if you change the usus and call things differently, they will change. It's pushing on a string.
Basically it's another incarnation of Facebook's "liking this picture will end world hunger" :)
No, fixing the world is not that simple. Just you wait, gender inequality - I'll replace all the "he"s with "she"s on my blog. Ouch that's tough blow, I can only hope my misogyne silicone bracelet will shield me!
"Unless your point is that you're tired of it coming out as an explicit point for discussion, as in this current thread of the conversation. That's optional to the core of the effort."
If one decides to be importunate and pushy (ever had that friend who wouldn't talk about anything else that 9/11 conspiracy, for example - be it at work, at lunch, parties...?) - fine, but don't be surprised if it creates backlash and is counter-effective on occasions. It's a trade-off that should be weighed in. You're free to use that tactic just as I'm free to comment on it :)
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.
Philosophically, programmers can do anyones job, as long as that person is willing to describe it in a way that it can be abstracted properly.
Programmers are unique in the world, in a philosophical sense, in that the skills and techniques of programming can be applied to any human subject, and seriously productive results can be attained. Computers are an "infinity machine" in that any single subject that a human being can describe, using words, can be in some way supported by computerization.
So if you think an organization is broken, programming can often-times fix it. Good programming, which encodes the domain-specific knowledge of the organization, can be applied to any particular role in human existence - including that of management. In that sense, programmers are able to operate exterior to any organization - and must, in fact, if they wish to deliver a productive result - and apply their skills to that organization in order to improve it.
Programmers who have worked professionally in any industry have an intuitive understanding of this fact, and its strengths.
So I would put it to you that its not Stockholm Syndrome you're observing, but rather this simple fact: Programmers > Managers. (Well, Programmers who deliver working systems, that is..)
There are good programmers and there are bad programmers. There are good managers and there are bad managers. The good variants of either are very valuable and can deliver huge value to very diverse businesses. The bad ones, not so much.
Since the computer-based automation of everything is a reasonably recent phenonomen, there have been more low-hanging fruit to be picked by bad programmers. Management is a much more mature field, so having "Teach yourself Management in 24 hours"-level competence is much less likely to have a positive yield.
What you're describing is just general intelligence and analytical thought. It's harder and rarer than most people think, and both managers and programmers to be really good at their jobs. But just as there are less demanding management positions in the world, there is an emergent class of programmers who are perfectly capable of building and maintaining simple CRUD apps to spec, but wouldn't need to know half of what is in this guide to be effective.
> So if you think an organization is broken, programming can often-times fix it.
Believing this fallacy will bring you nothing but suffering.
If an organization is limited - if the will is there to do the right thing but the workload is more than the people involved can handle - then programming can indeed help, by amplifying productivity.
But a broken organization is not merely one where means are insufficient. It's one where you are forbidden to do the right thing. That's not a technical problem, it's a political one, and no amount of programming can fix it. You have to either get into a political fight - which probably isn't your area of comparative advantage, but best of luck if you do take that approach - or get out and find a job somewhere less dysfunctional.
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.
Take care not to throw the baby out with the bathwater: fixing the problem can be easier than finding the perfect pink elephant and praying it stays that way.
Of course, do take care to throw out the bathwater.
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.
Hah, no, but I see I didn't provide enough context. I was referring to the subsections in "Personal Skills", "Team Skills" and "Serving Your Team". I also freely admit I am jaded by poor management in the past that has not responded to the kinds of advice given here.
"Go home if you have a contagious disease. You should go home if you have suicidal thoughts. [...] You should send someone home if they show serious mental malfunctioning or signs of mental illness beyond mild depression. [...] Don't use cocaine or amphetamines to combat fatigue."
"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..."
I disagree. I think it is only very narrowly applicable, in particular to companies that are technology-centric (i.e. that have as a primary product something that is technology related, such as a software product), and even then it only applies to a fraction.
In most companies, technology-centered or not, the non-engineers have a large amount of power to "create and sustain" something far more important than code or systems: institutional political power. I don't care how good a programmer one is, in such organizations institutional politics almost always wins. The old addage, "It's not what you know but who", applies here, as in any other industry. Talent is only good to carry a person so far, within the confines of somebody else's business.
Here's a shorter version: Are you so inspired by a software product or service that you are driving yourself mad thinking about how it was created? Great, do whatever you can to write your own version. Keep at it. Seriously, keep at it. Are you so obsessed with figuring this out that you are unaware that hours are passing by while you work? Awesome. You have discovered a true passion. Now you don't need to read things titled "How to Be a Programmer" because you will drive yourself to become one innately.
For everyone else, go ahead and try to read things titled "How to Be a Programmer" but don't expect it to actually help you, you know, BECOME one.
Wow, hold your horses cow boy. Did you even read the article? It's about being a programmer in the real world; that is how to communicate effectively, know when to tell management that you think a certain decision was a mistake, how to approach project schedule estimation, and so on.
As a young hacker who's not sure yet where he belongs in the world of tech & science & engineering (worked freelance, worked in startups, worked in research as a grad student, worked in larger companies, and I still don't know what I want to spend my life as a hacker doing :-), I found it extremely useful and well written.
Excellent way to become an arrogant coding cowboy. "My passion is so great so there is nothing anyone can teach me. Just by hacking alone in my basement my innate ability to write efficient and correct code have started to bloom."
+1. Your short version pretty much summarize what other 1000 people would say. And that's what I told people who came to my school's open house today: look around you and see what kind of things you wish you could control. You want to be able to get all the files with certain prefix? Figure out that linux/windows command.
The title "A Short, Comprehensive, and Personal Summary". This is not short. It's pretty verbose.
It's hard to be short and comprehensive. This is shorter than a book, longer than a magazine article. (55 pages: OK, maybe a short book.) "Short" is relative. :)
His coverage of debugging, and how it's critical to overcome fear of breaking things, and of asking the right questions of how things might fail in this way, is a great explanation.
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 in English ? Especially when in male dominated jobs like programming. A programmer is likely to be a he than a she, so why try this hard to be politically correct.