Keeping Your Company Asshole-Free
blog.hackfwd.com
blog.hackfwd.com
People either:
- Hacked together the internals to make it function, never considering any of the existing Backbone or _s functions
- Figured the existing code was a template, and rewrote it all now they thought it should've been (which can be good or bad)
- Learned enough of Backbone to complete the example with minimal code, but generally took longer because they had to learn the tool first
As a result, I got a great hire that knows when to refactor, when to leave existing code alone, and when to use AngularJS instead of Backbone!
If a company I'm trying to find employment at wants me to take my interview home for the entire weekend, it sends all sorts of bad signs:
1. They don't see working on the weekend as unreasonable.
2. They don't value my time.
3. They aren't comfortable making hiring decisions and taking on risk. What other hard decisions aren't going to be made or are going to be made too late by this company?
1. Nobody here works on weekends. In fact, it's not well received, but tolerated. 2. Everybody's time is valued here and on a individual basis. 3. I'm glad i had influence on whom i will be working with on a daily basis and have not regretted it either. My workmates are awesome. Why should the management decide this all alone?
Everybody here is free to openly make reservations about the companies strategies and decisions.
THAT is time management.
Maybe give them a project that only takes a couple of hours, just creating a simple module that does some very basic thing. Try to find out how they work rather than the final result.
Edit: I might be thinking of this, or something like it: http://www.businessinsider.com/what-does-your-use-of-the-wor...
Specifically, in most cases it's expected that you specify the subject of a sentence, which happens to be yourself a lot of the time. There's no such expectation in Japanese for example.
I actually try hard to use I wherever possible for that particular reason. Saying "I think a message-passing style would be best for this" is more honest than "a message-passing style would be best for this".
Writing this on computer that asshole created.
And btw, I do not know a single Genius (with uppacase G) who is not an asshole, so go figure...
I do. That type of intelligence does not predetermine being an asshole. I think it's sad that people think that.
By "Genius (with uppacase G)" you mean an Apple Store employee?
He claimed his employer was trying to "milk him" by asking for a handover guide for the next person taking over the role.
I think that people hold onto information for power, to protect their position and to give them leverage over their situation.
Although people bringing their stapler to the IT help desk is one of those times I might not be mad if the response was "That's not my job"
In the case of these team members I think one comes down to fear of maybe looking daft in front of the rest of the team by saying something that they think might be wrong. The other can just be a sanctimonious prick and will ask people questions that they simply wont know the answer to, to show them up in front of the rest of the office.
So in my experience fear is certainly a factor holding a person back. However on the flip side a person lording his knowledge over other people but not sharing it in a useful way conducive to improving the general programming knowledge of the team.
They both harm the team but in different ways. I don't know how these two problems can be solved though. Maybe encouraging opinion from the people who fear sharing their points of view and being supportive of them would help.
I'm at a loss though with regards to the power-bitches that like to make people look small with their own knowledge.
What I'm guessing you'd like sanctimonious pricks like me to say:
"That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use."
This categorically does not work! Don't do it! It allows for zero shared credit, puts everyone on the defensive and leads to bickering and bike-shedding. In the best case, the person you're arguing with will disagree vehemently, go away for a few weeks, then come up with a new idea all by themselves that is exactly the same as what you were arguing for. This achieves the same result but isn't a very pleasant way to get there. Questions work marginally better.
In general my lines of questioning follow one of the following formats:
1. Is there a reason we're not using <a := some no-brainer technology choice> instead of going to all the effort of rolling our own <a>?
2. Have you thought about how that's going to work when <one or more use cases that are almost definitely going to happen that you clearly haven't thought about>?
3. Is <b> something we're just doing now to get it working and then planning on refactoring later? <where b := a horrible mess they just merged into master>
4. It looks like the script is running when I enter <script>alert('bazinga!');</script> as my username. Seeing as it's your commit that caused it would you mind taking a look at that?
In terms of sharing insight without offending people, that's about as polite as I can get I'm afraid.
If A1 asks those questions to B1, I suspect that A2 would view them as perfectly normal, appropriate and helpful, while B2 might view them as aggressive or "trying to show A1's superiority".
The example I was giving and probably not stating clearly enough, was of a member, who on a number of occasions has approached other team members and asked questions out of context like an on the spot quiz.
As an aside to my first post it's also interesting to see the people that will openly admit whether they have messed up.
Anecdotally it is usually the people who are less willing to share their knowledge that will try and shift the blame.
BTW, I am revoking your sanctimonious prick status....
This categorically does not work"
meh, if that gets the job done faster then say it. The chance of a 20 minute argument vs a weeks long delay? I'll take the 20 minute argument.
But then again, leading questions get my back up. I'm a "say what you mean, don't hint at it" type.
If I get offended because someone else knows better and tells me so without being rude, then it's my problem (and my insecurity), not theirs.
I think it's possible that you misread my comment. In this scenario you get the 20 minute argument plus the week long delay, at least in my experience.
In those situations, it is a lot less effort to allow developer B to commit whatever the hell they want into the codebase, wait until they lose interest and then go in later and clean up the mess.
In case you think I believe I'm always an arsehole, this isn't the case. But there have been times I believe I was. I'll have to work on it in future :(
http://www.slate.com/articles/arts/books/2012/10/ascent_of_t...
Though your term used to define it is wonderful. I would major in asshology if given the chance. But it would require a minor in chraminology. :)