62 karma · joined July 6, 2012
If anything I'd think the appropriate response would be sitting him down and saying "look we appreciate you are an enterprising risk-taker but we have certain expectations here at mega-corp" Once he was a sufficiently brow-beaten corporate drone then they could have pile monotonous work in him/her ad infinitum. Win Win in my mind.
>Why are you ignoring everything else that has come up about amazon's culture?
I've read the articles, but its important to remember that if you've had a bad experience you are 10 times more likely to be vocal about it(that shit is some straight science - http://www.nytimes.com/2012/03/24/your-money/why-people-reme...).
> guess his job description should have been: "do what your manager says" ?
I'm not a scientist but I am pretty sure that is the definition of a job.
Having been both an engineer and a manager and an engineer again I can honestly say my smoothest projects were composed of folks that were great followers. They understood when they needed to take initiative and when they needed to follow instructions to the letter. When intentionally adding a leak to the abstraction was necessary to get something out the door and when their code needed to be bullet proof.
Alpha programmers are different animals. If they are truly an Alpha programmer then I use them like a flamethrower loosely directing them at tough, solo/small team problems. But I've encountered my share of C/D players that labored under the delusion they were an Alpha programmer. These folks lashed out, constantly questioned my judgement, and eroded the team's cohesion. Somehow they managed to do this while also not being capable or qualified to tackle my big picture problems. I afforded them every opportunity to be successful, but in several cases they were just too smart for me I guess so I had to set them free. This article sounds like a my many meetings with the latter.
As for advocating being a sheep. Some things are bigger than one person. Is the defensive end on a football team a sheep for following the play the QB/Offensive coordinator has chosen? He may not be put in the best place to make a tackle or a sack(very prestigious stats) because his role might be more subtle than that (containing the quarterback). This is what you do when you are part of a team. Why are you advocating going rogue?
So often engineers and quants take it on themselves to define "results" but is that fair? As an engineer these are lessons hard won over my career. I am a component in larger system. What if the alternator in my car took it on itself to improve engine efficiency, fuel economy, or safety at the expense of the job I expect it to do?
One of the most important things an engineer can learn on the job is humility. Understanding that the don't have all the information and accepting the tasks they are given. The author admits this is not what they did and they deserve poor marks as a result. No promotion? ... color me surprised.
its bad for the company because the candidate can work with someone else and produce a glowing submission. I have helped a number of people do these some that have gotten the job.
its bad for the interviewee. They may spend 10-15 hours on this and get rejected for no reason at all. Do you think the person reviewing the submission is putting multiple hours into it. Doubtful.
If the intent is truly(and I mean truly) help individuals that struggle with traditional interviewing techniques then kudos. Demonstrate this by allowing candidates to interview in a way that is comfortable for them(including not taking your take home test) If its the company saying "my time is more valuable than yours. Do this assignment then we'll talk" then no thanks.
I prefer an interview system where the company and the candidate both care. Commitment is a requirement for everyone.
The problem with them is fundamental: "You will only get someone desperate enough to take your exam."
If the person is qualified they will be swimming in opportunities and will likely throw your exam directly in the trash heap. If they aren't you probably don't want them working for you. I suppose these might work if the entire industry colluded on it but then ... prisoner's dilemma.
Maybe a more useful indicator is weeding out the candidates that didn't say "no thanks." Cause really why are they so desperate for a job and why do they have all this free time? but then ... ethics.
The key is having information specifically to formulate your company's BATNA. The notion that salary sharing is bad for the employee is hogwash from unfair labor practices developed over decades.
Would you buy a car from a dealership if the dealer told you "you shouldn't comparison shop it will only make you resentful"? Yet we are willing to accept that claptrap from a company. Not in this lifetime.
In one breath she states its "illegal to retaliate for sharing salary information" yet a spreadsheet she implies clearly evidences discrimination hasn't found itself in the hands of a qualified attorney. If the former is true barring legalities I may not be familiar(disclaimer not an attorney) the participants would seem to be protected.
In addition she strongly implies damning evidence can be demonstrated with some "spreadsheet magic" but is very careful not to use specific language. This could be construed as someone avoiding accusations of libel.
I'm interested though if this spreadsheet has the level of adoption she claims(thought I don't quite understand the bit about 5% of former co. if she means google that'd be 2,500 people) It will certainly leak then we can run the pivots ourselves.
This is my primary complaint regarding rebasing and no-ff. It leaves all these useless and confusing commits around. A lot of times the content of the commit was undone by a commit in the family. Its usually not useful to anyone and can only be reasoned about by the original author. When you merge all that crap lands in `master`
Interestingly I think I am actually learning something during this thread. The hardcore `no-ff` actually misunderstands rebase. They find the billion crap commits to be disruptive as well and want the merge commit so they can get rid of that mess. But I just say the mess is unnecessary. Just squash and you get the best of all worlds. You'll never miss those 12 commits
This is my point I find the 12 commits to be unnecessary. I've never been burned by squashing. The only arguments I've heard against it are ideological(you're destroying history, etc.)
> Your last paragraph is a nice example of psychological projection. If you weren't so narrow minded you could have used your energy to learn something.
well thats clearly ad hominem nonsense. So nothing to see there.
>Myself I use --no-ff because it fits the kind of work I do very well. I haven't lost a minute of sleep or time over its deficiencies. And I am pretty certain that I spend a whole lot less time fiddling with git than people who advocate "agressive rebasing".
No point to any of that either.
>Also merging two branches that tend to touch upon same modules but are not kept in sync all the time (due to whatever reasons) is a lot simpler when you use --no-ff.
This might have some merit. But I don't really understand what you mean.
>You say that these properties are bullshit, but I found them invaluable when fixing bugs and architectural defects and where it was important to find out when and how the bug or a behaviour occurred. And funny that you mention accountants and auditors. Because being able to do forensics more easily on the codebases that I worked on has saved me and my clients many hours and gray hair. And I have found myself in situations where
Here you actually makes some points but they are all anecdotal. How many hours has it saved you? How could you even know this unless you split time into two parallel experiments and measured them independently? Its not that there is anything wrong with relaying an anecdote. But when you introduce this handwaving nonsense as justification for something as though it has the same strength as an objective measurement that I call bullshit.
>I do admit you have some merit in pointing out how bad a git history looks when littered with merge commits for single commit branches. But then, this is pretty easy to fix. Just use a fucking vanilla merge, or indeed a rebase when it fits the problem. Another way to work around the bad aspects of --no-ff approach is by using a better git history explorer.
After all those words here you start to make some sense. Of course I would use `no-ff` if I saw some value in a "merge commit" which is the mirror to your point. But my point is just that ... I've never encountered that case or had it concisely explained to me
I mean its certainly possible that in some tiny fraction of cases I might say "man I could fix this a lot easier if I had the merge commit" its just in the 10,000's of examples that form my experience I haven't stepped on that particularly landmine yet.
Even with that said, my development philosophy compels me to choose "Simplicity over Completeness" and is utilitarian to the core. I will chose whatever is most effective in the vast majority of cases.
Some folks look at "Source Control History" as some pristine, historical record of how things went down. Since I am not an accountant or auditor this has little value to me. It encumbers the day to day to optimize for a case that is almost certain to never happen. A first-order approximation of the history that optimizes for the day-to-day needs of an organization is far more suitable in almost every case.
I use the term "local team pedant" its not a bad thing. Some folks just have a need for things to be "complete" and feel compelled to do so for irrational(usually expensive) reasons. In my own experience the person that is the "no rebase/ never fast forward" cheerleader can never give a solid objective answer as to what the benefit is. Its usually always something like what this no-ff-er suggests(http://walkingthestack.blogspot.com/2012/05/why-you-should-u...) . Things like "I can see whats on a branch, etc." That in itself is not a justification. Its just words. If you could someone how demonstrate how this reduces development costs or offers a better way to organize work and is simultaneously better than the more idiomatic alternatives then I'm all for it.
From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. It gives them something to do between harping on whether your behavior is in the correct "domain", deciding if a list comprehensions are truly "pythonic", and spending that extra month perfecting the event sourcing engine to revolutionize the "contact us" section of your site.
Sometimes the only way to jump over the heads of the paymasters is to do something for free.
Right if your goal is to make truckloads of money sure. Not all software professionals ascribe a great deal of value to this end. Many major advances in bringing high-end operating and distributed systems to the masses have come from "Open Source" movements. Is is that hard to imagine a more protectionist, profit-driven software industry where these technologies are shelved in favor of propping up current money makers? In effect denying cheap, high quality solutions to a generation of innovators and start up companies?
As a side note I found your call for unionization to be a flawed comparison. The organizations you've alluded to (AMA and ABA) deal in inelastic goods that enjoy popular legal protections. This is for good reason, no one wants brain surgery from an amateur, but I might give one a shot at standing up my wordpress site.
Secondly, this is not a limitation of source control tools its a limitation of formal logic.
Vertical alignment's benefits are absolutely minimal. What is the ROI? How many bugs can be traced to "Lack of vertical alignment"? How many programmers have uttered the phrase "That vertical alignment really saved my bacon on that one"? Answer NONE! Its entirely aesthetic. I agree it looks nicer, but a Geo Metro modded to look like a Ferrari isn't any faster because it "looks faster"
Agreed, but its not the only objective. There is a balance to be struck. Speaking from the perspective of an individual that delivers software as part of a team:
producing readable/understandable code == GOOD
letting your aesthetic preference be disruptive == BAD
As an anecdote I have worked on teams where a certain individual's need for symmetry in the code base has significantly reduced the efficacy of source control and caused issues particularly with automated build/deployment.
When I criticize "readability" its not because I don't believe its important, but rather because its too often used to justify one individual's preference without regard to objective counter criteria and too often embodies "The perfect being the enemy of the good"
This may be a problem, but if I am working with values like this I am typically using a spreadsheet. I imagine this is more of an issue in simulations and/or scientific applications.
For general use code, epecially code being worked on by multiple people this a bear(specifically because of merge conflicts). I typically find the advocate to be the person that has the least team experience.