Comment by azanar | Hacker News Reader

Comment by azanar | Hacker News Reader

Parent Full thread

understanding that not doing something right doesn't necessarily mean you're doing it wrong

But it might; that is the other half of pragmatism. Being pragmatic is not just a softer way of saying self-defeatist.

And don't be so dismissive of theory. To quote W. Edwards Deming: "Experience by itself teaches nothing...Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence without theory there is no learning." Just doing what you discover is done in practice provides absolutely no room for improvement outside of rare flashes of intuitive brilliance. Theory is not just an abstract description of what has been observed concretely so far; by far the greater value lies in the ability for theory to predict what has a likelihood of being observed in the future. Having a theoretical basis to work off of will give those experiences context, and will give you the ability to do a much deeper analysis. And analysis, if the comments Sara received are any indicator for, is something we need to be doing a lot more of.

My strong point is that I communicate well with people, and I'm not afraid to take an issue up with someone -- be it colleague, manager, or client. I will take initiatives to get things done. And even if I'm going to do it just once, I'll get it done _RIGHT_. I am decent developer, but some people take issue with me because I'm not as fast as the hack... I mean other coders. ;) I've heard people remark that I could be a Project Manager, but too bad I feel they don't do anything but useless admin work. (And get in the Developers' way!)

this paragraph smacks of "I do it right, everyone else does it wrong." my point was that the "right" way, as learned "in theory", is not necessarily so in practice (and in fact, often isn't when the theoretical right way involves spending client money that will add no value that is immediately noticeable to the client). i wasn't dismissing theory as useless--if you read my comment as tilting to that extreme, i probably wasn't clear enough. theory has its place, but if a dev goes through her career expecting her clients/bosses to agree that spending time refactoring so-so code (that works!) is worth $XXX/hr, it's no surprise she's getting frustrated. in my mind, her role as a developer is to apply sound theory as much as possible within the constraints of her job. when other people are signing her paycheck, she either does it their way or finds a new job (or applies to YC)--but complaining about it won't help her situation.

when other people are signing her paycheck, she either does it their way or finds a new job

If the people who hired her were thinking straight, they hired her for more than just her ability to write code to a strict specification under strict supervision. A number of developers are valuable far beyond their ability to make a computer do their bidding, and the employer who does not care does so at their own peril.

She may come off as a little overbearing, but I don't get the sense that she is unreasonably set in her ways. I get the sense that she's passionate about doing things right, and will take up issue when something doesn't make sense and push back until things do make sense. If you think these are the same, I'm afraid your model of developer behavior is flawed. Strong beliefs can be weakly held.

And it is possible that refactoring code that works is worth $XXX/hr. Consider the savings that might be accrued later on due to shorter bug-fix cycles, quicker feature releases, and less overall malaise of the development staff. Not everyone can be motivated by having their paycheck treated as a carrot on a stick. So the money might be very well spent.

eloquent strawmen aside, i don't disagree with your points. i just think that if the people who hired her thought the way you do, she wouldn't have posted in the first place. but, they don't, so she did.

Reply on news.ycombinator.com