Hacker News Reader

Comment by wccrawford | Hacker News Reader

She notes that she has a tendency to require that the solution work her way when coding.

I wonder if she realizes she's doing the same when working with people's problems? Almost all of those solutions end with, "do it my way or get out."

Not a collaborative coder? No room for you here. Not a people person? No room for you here. Want to use the latest technologies? No room for you here.

For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work with them, just to make them work for her.

View on HN

>For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work with them, just to make them work for her.

That's kind of the point. You don't want to be working with someone who can't work with other people. If you're a "troublemaker" and refuse to change and adapt to the way the company you work for does things, go ahead and found your own and do it your way, and see if others are willing to work for you in the long term, or find another company with the culture you're after. When it comes to tech there's plenty of companies out there who hire for different personalities and abilities.

I think there's often a way to use understand what motivates the "trouble-maker" (I dislike that label here) and use it effectively that doesn't take a lot of effort, just getting to know the person and letting them get to know your position.

I actually have a post about this: http://blog.alexrohde.com/archives/473

>You don't want to be working with someone who can't work with other people.

That describes me pretty well, and those with whom I work love me. They just keep me in my little box, leave me alone and let me do my work. But they are also a grown-up company that doesn't make people wear 27 hats. PMs do their job, Infrastructure does theirs, Client Support does theirs, etc. Not every job has the same requirements as every other job.

Yeah, because nobody would want someone like Alan Turing at their company.

The whole "everyone must be a team player" thing is such crap. I will gladly take a one man army with the resolve to deliver above all else over a team of mediocre players who take 4 times as long and waste more time arguing in meetings than it would take to just bust the thing out twice.

Effective teams are great too, but if you can't figure out how to use the other type, it really is your loss.

No. Most people think that they are Alan Turing, Linus Torvald, Steve Jobs; are not.

> Not a collaborative coder? No room for you here. Not a people person? No room for you here. Want to use the latest technologies? No room for you here.

That's corporate life in America. No room for individualism. But I've heard it's even worse in Japan, so there's that...

Eh, Idk if it's that bad in US; if anything the other countries are worse. If you want to scratch that itch find a startup that uses latest and greatest stack.

Of course there's room for individualism. But if you're going to make the rest of your coworkers lives a misery, you'll find that you'll be expressing your individualism in your own one-person startup.

How is doing something like re-writing a system in your off hours making your co-workers miserable? I mean sure, if you then proceed to bug your boss every day to adopt the new system after he carefully reviewed it and rejected it, I'm with you.

And she lists several "harmful" practices like this.

In short, taking initiative? Nope, we don't like that here in corporate America. Doing what you're told and minimize risk. Don't actually try to make us money or anything.

It's interesting that you feel comfortable extrapolating one person's opinion to represent corporate America.

They're not. Corporate America is pretty risk averse. 90% of any top 500 would freak out about that. Imagine a guy in the legal department rewriting the Eula in his spare time, or the hr director rolling in with a new employee handbook.

Software is a little special, because you can still kinda get away with that.

Agreed. Was hoping for better insight but not really getting much.

Currently dealing with a fellow that exhibits all four of the documented traits plus a general unwillingness to document anything. Kind of unsalvageable at this point... =(

The article misses some key things I would throw out there, here's to hoping they come to value with you.

1. Bake rules into your workflow. For instance, enforce daily or semi-daily standups. Make git commits a portion of things in those - so everybody has to say what they've done in git commits (obviously, this isn't 100% of things). Other coders on the team will be annoyed by the person who isn't committing code daily, so this will mean that coder is admitting not to you, but to them, they're playing by different rules.

2. Force them to write design docs for implementing new technologies, before they're implemented. Then write a retrospective about how things went over, a week or two after the project is launched (things that were unexpected?). This can serve as documentation, but adds a bit more clarity to the overhead that comes with these changes, which is easy to miss when you're in the thick of things. Perhaps it's all they need to understand what kind of complexity they're adding (or what kind of simplicity you're not giving them credit for).

> Almost all of those solutions end with, "do it my way or get out."

Agreed. My style is to contribute to creating the goals of the team in addition to the projects. She'd probably call me a trouble maker haha! And I'd be proud to be one. Aren't computer programmers supposed to be troublemakers? We're hacking the system ... ;-)

Working effectively with other people is definitely a skill. Some people have it from birth and some have to learn it. One blog post isn't going to solve everyone's problems but it is interesting to hear her experience.

> Aren't computer programmers supposed to be troublemakers? We're hacking the system ... ;-)

No, we're not, and no, we're usually not.

Ah jeez lighten up. I was joking. Hacker culture did dominate in the early days. Phone phreaking, etc.

50% agree, but 50% I'd say that as a leader things need to get your way or out. That's pretty much your job.

I would rather work for someone that lays out the problem to be solved, documents the constraints, and unleashes smart people.

I have been in the position where the VP of IT wants to have his cake and eat it too: VP salary while micromanaging variable names that the dev team uses so that he can relive his salad days as a tech lead.

> I have been in the position where the VP of IT wants to have his cake and eat it too: VP salary while micromanaging variable names that the dev team uses so that he can relive his salad days as a tech lead.

While that may be the reason in that particular case, it seems to me the more common problem for micromanagement isn't a desire to relive one's days in a position lower on the org chart, its simply lacking the skills to operate at one's new level. Or, I guess, a corollary to the Peter Principle: people tend to work at their level of competence, despite being promoted to their level of incompetence.

True. But most things the leader cares about are things we as developers don't care about. E.g. he wants people to work together because fights are unefficient (we usually don't care if we are not involved directly), he wants certain processes to be applied so that departments we don't think about also get the data they need to do their jobs, he wants to be able to answer questions in the meetings he goes so we don't have to.

So yeah, the technical problems should be open to solve for me as I and my team think. But there are a lot of things my manager should define for me and care about even if I don't. That's why he's part of my team.

Managers I respect would more accurately be described as saying "join the team or get out".

My favorite managers are coordinators and facilitators. They listen to everyone's input, above and below them, and stear the ship towards success. They gauge input commensurate with the experience and knowledge of each person from whom it came. They make decisions with special sauce that can't really be boiled down to words. They're transparent, communicative, thoughtful, available and appreciative.

If the manager has heavy experience and success, it may sound like he's saying "do this my way or get out". For example, Steve Jobs felt he had great taste, and many people felt he was a jerk.

He obviously received input from a huge number of people and couldn't have made Apple successful alone. He discusses how Apple recovered in the late 90s at D5 in 2007 [0]. The NeXT brainstorms are also interesting to watch [1]

[0] https://youtu.be/wvhW8cp15tk?t=23m42s

[1] https://youtu.be/BNeXlJW70KQ?t=2m1s

Reply on news.ycombinator.com