Comment Re: brilliant and dangerous? (Score 1) 1134
>If their code is so useful in the first place (and it is by virtue of the fact that most companies would rather hire one talented developer than several mediocre ones), why not ensure they stay?
>>Because it is usually quite possible to hire developers that are just as good, but that are not jerks. They may be slightly less brilliant, but they make up for it because they can actually work well in a team.
Presuming your original assertion is correct. I'm not convinced that brilliance is mutually exclusive of teamwork; else how do you explain Oppenheimer and the Manhattan Project? Personally I've always felt that
a true measure of a man is not his dick-size, wallet, girlfriend, car or what have you, but rather his ability to work with others to accomplish a goal -- note there is no presumption of liking a person built into that
statement. I've worked with people for years I would have cheerfully beaten to a bloody pulp and paid for the privilege.
>By way of disclosure I am one of those developers - and I argue to have things taken off of my plate (documented, designed etc) outside of my scope specifically because I dont know what will happen tomorrow (hit by a bus, food poisoning etc) and a team of people like u most likely will take over.
>>First of all, you assume that I'm one of the "rank and file" devs. In practice, I had been in the role of "star developer" in my division in the past, so I know how that works from the other side. But note that we aren't talking about this phenomenon in general, but about a very specific subset of such people, who are "good" (for some definition of it) on the technical side, but are arrogant and uncooperative with other people whom they perceive to be lesser.
I get arrogant all the time; I'm also the person people come to when they're having: a) legal problems b) medical problems c) life problems d) work-related problems e) loans f) cheering up. Arrogance (as a word) is nothing more than someone's description who knows their shit cold *and knows it*. I dont presume to know everything; I do presume to know that *what I do know*, I know *well*. I am extremely uncooperative when it comes to bullshit. I am *extremely* cooperative when it comes to solving business issues including employee quality-of-life. I fit the articles profile quite well, and I am sick of hearing about it -- y'all are venting, which I understand - this is merely my response (that if you brought this up in front of said coworkers, they would undoubtedly mirror) -- GROW UP, GET A THICKER SKIN and READ/LEARN OUTSIDE OF WORK.
>Your requirements for (excessive) documentation is a direct transfer from my finite amount
of time available on this earth (solving problems) subsidizing your mediocrity. GROW!
>>Why do you assume that I require "excessive" documentation? When I say "bad docs", I mean stuff like 50 kLoC of code that has not a single comment in it; not forgetting to fill in the "detailed description" in the documentation comment for a private method!
When someone usually bitches about documentation, its generally because they want every function documented with fancy descriptions & uml. write your code small, modular, with unit tests. its not rocket science.
If you do something tricky (like using a GPU to calculate veroni diagrams) then include a link to a paper, or a psuedocode overview of the algorithm/engine in question; assumptions on input, same. todo/suggestion for improvement, same. other than that the code should pretty much speak for itself.
>>By the way, regarding the "finite amount of time" - that's all well and good when you solve problems for your own sake.
I would say stop right there
>>But when you're at work, the time is not "yours", really - it's bought by the company you work for, and you should use it in a way that's more efficient for the company. Sometimes that means being more patient when it comes to dealing with abilities of people around you, even when they're lower.
Mate I can deal with down to mentally-challenged (and do); what I do not tolerate is willful ignorance, sloppy execution or the executionable offense of sloppy thinking. I expect my workers to learn and improve upon their processes, regardless of what their personal tendencies might be in their own lives. I'm patient (and happy to explain something) the first or second time someone asks; its the third+ that gets the irritation. That is whats picked up as surliness in yond article. And that is what I'm protesting -- if a *team* can't fix something in two days, and a single dev takes 1 hour, there is something seriously out of whack with the teams skillset; its called a debugger, at the very least single-step through the execution.... my response to a situation in which my skill is inadequate (which happens fairly frequently) is to *LEARN*, most of the time sans benefit of teacher. I expect that anyone I work with to at least attempt to learn.
>>I was in that position as a senior dev who got promoted to lead very fast, and had to learn to manage a small team of my own. I had to struggle with that "if you want to do things right, do it yourself" attitude. Yes, I could do it better than my juniors could, and faster as well. But you know what? Once I've learnt to delegate appropriate tasks, and, when coding, to keep in mind that I may later want to assign the mainenance of that bit of code to one of the juniors, and dumb things down sometimes, or at least comment the "smarter" pieces even when they would be obvious for myself, I've found that the overall productivity of the team increased - precisely because I could offload those maintenance tasks to them, and keep working on new code that truly required more knowledge and experience to be done right.
Me I just fix'em. And if they can't get fixed, they get fired. I do my job; I expect my subordinates to do theirs. If you aren't showing up to work, I sure as hell ain't baby-sitting you. The customer is also *not always right*. There's a certain amount of coddling I'm willing to do to earn a buck (or a customers rather), but if I'm hired for my expertise, I dont recommend/perform shoddy work. Just 'cause you think that blinking puke-green on orange dialog-box is the perfect way to alert someone doesn't mean I'm willing to implement it.
>>If you keep writing more and more code that only you can maintain, then, eventually, you'll end up doing nothing but maintaining that code - and that is usually not fun.
and thousands long for immortality who do not know what to do with themselves on a rainy Sunday afternoon; I ain't coding for fun, I'm coding for (my companies) profit. and if you're a coder/dev of any skill, you'll eventually have to write something that is mission-critical (that can't be bought, or outsourced) and that my friend, the maintainance of which, my friend, *is* your job - fun or not. Do it right the first time and you won't have to do it again
I think in the end, what I'm irritated about is the decline of *standards*. and I see documentation (past a certain point {as defined by the author}) to be yet another example of the decline thereof.
whatever happened to genius is 99% perspiration, 1% inspiration in this country?! If you don't bother spending any time *learning* the code that critical to your company (be ye the author or not!) then
what good are you *to your company*?
