As a relative newcomer to the software industry (~2 years), I hope the grumpiness caused by shifting requirements decreases over time. That after you gather enough experience, you are able to predict more and more accurately what the requirements _should_ describe and act accordingly by preparing some hooks, dangling bits and all other kinds of flexibility so that you can leverage it quickly once the change kicks in.<p>A more experienced friend of mine (10+ years) says that it is indeed more or less possible, but to do so consistently one has to be quite exceptional engineer - and psychologist. Well, if he's right, then at least I have something to strive for :)
The part about "Creators, not builders" resonates with me, and it used to make me very resentful when people viewed me as a producer of the codes rather than as a contributor to the creation of a product. The author of this piece is absolutely correct that most people got into software because they realized they could create, not because they could build up someone else's idea.<p>That said, this bothers me much less than it used to, largely because I see it as a choice rather than something that is imposed on me. There are plenty of opportunities to create if that's what I want to do - but I understand that this doesn't tend to happen when someone directly pays me money to write code.<p>Why does someone hire a software developer? Almost always because they have an idea about some software they'd like to have written, and they are unable to do it themselves, which is why they're giving the developer the money in exchange for working code.<p>I certainly don't think this is how the best software is written. I'm under the impression that many ycombinator applicants (as well as google and facebook) start with programmers creating version 1 of the product that will eventually become a company. A couple of business guys thinking up an idea and then hiring a programmer to "code it up" doesn't seem to be the winning formula.<p>But I've come to understand that if I want to produce the codes in exchange for the moneys, I shouldn't be too resentful that my insights into the product aren't really what I was hired for.<p>Now, I do think this is a perfectly good reason for a developer to <i>leave</i> and look for a new gig. I just wouldn't be resentful about it.
This article resonates with me, I really appreciate it!<p>I would like to add a source or two of grumpiness.<p>To the "Work cross-functionally" section: it is possible to be injected into the creative process too early and too far. I may be creative, but I am not a replacement for a designer or graphics artist. I can sketch a wire frame, but I get really grumpy when someone says "now we want a screenshot of what it would look like in the real website."<p>Also a source of grumpiness is being expected to know everything about computers and be able to do/fix anything. As a programmer, if I say I can't administer a production level server, I hope that will be respected and someone qualified will be found to take care of the task.<p>I know there are really talented people with a wealth of cross domain knowledge and expertise, but for me - I'm a programmer, Jim, not a graphics artist or a system administrator.
Excellent article. I recognize in myself almost all these sources of grumpiness and callousness towards them to different degrees at the places I have worked. Never have they been so well laid out though.
Replace "wombat" with "software engineer" in this book, and you'll have it <a href="http://www.amazon.co.uk/gp/product/061886864X/ref=oh_details_o02_s00_i00" rel="nofollow">http://www.amazon.co.uk/gp/product/061886864X/ref=oh_details...</a>