> Umm, I seriously doubt that "almost everyone" in the state of Georgia in 1832
Touche. My point was that participation was extensive and varied. It remains to be seen whether or not this effect holds for women or minorities, but even if it didn't, that would only support my main point: context matters.
> A small event known in the US as the Civil War... just might have had something to do with this.
The authors address the Civil War in the piece. It would indeed have been a weird oversight for economic historians studying the pre-war South if they hadn't, if that just never occurred to them as relevant.
Some of this sounds like it really complicates the layout code, but I'm not sure I'm reading it right. Take, for example, a standard dialog template. If I have a large number of dialogs for editing user/products/whatever, all with the same basic `<div><label><span><input>` layout, it sounds like he's saying that I can't rely on the dialog template to format my labels, I have to apply the `dialog-label` class to every label in every dialog. Almost every tag in my doc will have a class attribute, since I can never rely on selectors to apply the right styling. In general, selectors are almost never used and classes do all the work.
Am I reading this right? Or are templates an exception? I need to re-read the template/component thing a few times to figure out exactly what nomenclature he's using here. But in general, I'm not sure I see the advantage of `.modal__form__item` vs. `.modal .form .item` except that the first is exponentially more verbose in the html.
I think you've read it right. Your HTML is more verbose, but you get used to it. I have elements like <h1 class="product__head"></h1> and it seems ugly and redundant (the h1 already indicates that the element is a heading!), but the advantage is that your CSS rules have a narrow scope (fewer collisions) and are easier to maintain. Further, your CSS is no longer coupled with your HTML. I would use .product__head in my stylesheet instead of .product h1 or h1.product__head. Then, if someone changes the h1 to h2, the stylesheet doesn't have to change.
Essentially, you just have to treat your HTML class names as hooks into your CSS; that's their function. Your CSS rules should not be concerned with your HTML structure.
You work as a development project manager, don't you?
It takes a certain kind of unique mindset to encounter excellent work somebody has done and use it as an opportunity to bash them because unrelated teams with unrelated skillsets are not churning out the features you want at the rate you want them. How in the world is doing his job the best he can do it somehow not the best use of his time?
What exactly is your argument here? Is it that appfolio should not hire such excellent front end developers because their backend is still lacking? Or is it that the front end developers should do worse work to mesh better with what you consider to be the failings of the back end? Even if the css author had anything to do with your complaints, your argument betrays the absolute worst mindset that one can find in software management: the idea that quality work is time-consuming rather than time-saving.
> So I would venture that, for any pair of moderately experienced developers, it's almost always possible to find a pair of tasks such that one of them is twice (or even ten times) as fast as the other.
I completely disagree. The FizzBuzz syndrome is very real: when I do developer screenings, the majority of candidates simply can't program even tiny problems. There's no way they're faster than anybody on my team at any development-related task. And yet, they all have long resumes and a lot of experience. All those people are working someplace. And I've watched these 1/10 developers at work: they copy/paste lots of code, program through trial and error, and spend most of their time in the debugger. Eventually, stuff gets done, but excruciatingly slowly.
Once you reach a certain level of competence, then I think what you're saying is true. But there's a huge number of developers who don't reach that level.
On the other hand, I agree with you about this article. Some sort of insight on where this dev spent his time might have been interesting. Whenever I read things this vague, articles based on vague impressions rather than any hard metrics, I'm left wondering which side was actually incompetent here. Maybe this was one of the 1/10 CTOs, completely incapable of effectively communicating with people who don't fit his favored personality type. And if the feature the dev was working on was replaced with something else that only took 30 minutes to implement, maybe the original design was simply unworkable.
The fizzbuzz syndrome is real alright. But someone failing fizzbuzz is not an indicator that they will always be incapable of development. It just means they are very junior and require training. Frighteningly for the West, Indian and Chinese companies appear to grok this and actually develop their employees. US and UK companies throw their hands up in empty self-satisfaction that their work is so intellectually difficult that people up to the challenge are impossible to find. The reality is probably that the corporate business model is flawed meaning they cannot afford the seniority of guy they need.
I worked with a developer for a year and a half, who has 11 years of experience, who cannot code fizz buzz and cannot accomplish basic tasks. I have to hold his hand through even the smallest changes or bug fixes. These people exist.
He just got a new job at a large company with a significant pay-raise. The industry is filled with people who are, to put it bluntly, incompetent.
edit: that last line is a little harsh. I don't mean "filled" as in entirely or even mostly. I am just trying to say they aren't uncommon.
By the time you're evaluating someone with FizzBuzz, they're trying to convince you they have training and have developed from "very junior" (to wit untrained). FizzBuzz is the kind of test which should be a pass/fail final exam question for a 6-week Beginning Programming course, not something any degreed entry-level candidate would have trouble with.
Can they be trained? sure. But when applying for jobs, they're expected to already have training up to basic competency for the position. A restaurant shouldn't have to teach a prospective cook how to make a grilled cheese sandwich, an auto repair shop shouldn't have to teach a prospective mechanic how to change a tire, and a software house shouldn't have to teach a prospective programmer how to write FizzBuzz.
If such training is in fact needed, then the higher education "industry" is broken to the point that businesses should just get kids straight out of high school and take 'em from there.
The FizzBuzz question should really be "write me 3 versions of FizzBuzz, explain why they're different, and under what conditions would you use each over the others."
The fact that the FizzBuzz issue is a matter of whether the candidate can write it at all - and that so many interviewers don't view a "nope" answer as a full-stop red flag - indicates a baffling state of industry affairs.
The problem is that these people are supposed to be programmers, i.e. people who have been trained already. Yes, it is real that companies do not want to train people - and that is a problem in itself. But if someone tells me "I am a professional programmer" and I give him FizzBuzz and he cannot solve it it is no training problem. It is a problem with hiring: How could such a person ever hold a position as a programmer (without "trainee"/"apprentice" behind their job title)?
I doubt is a matter of seniority, its a matter of criteria, the way I see it is, FizzBuzz is useful only to weed out perhaps the lower 5% of the developers population and perhaps the lower 20% of the general literate population?
As an anecdote, I asked my wife, who's not a developer, she is an executive at a large beverage company, to solve FizzBuzz and to explain to me how she would do it and she did it successfully. She didn't use the word "for" or "while", but she explained that she figured there must be something that allows you to iterate over the same algorithm several times (paraphrasing).
Personally, I think FizzBuzz are useless unless you use them as part of a submission form before candidates send in their resumes, sort of like a slightly harder captcha. There is no place for a FizzBuzz once the company is already engaging with the company, if they are not able to solve it they will be earlier signs that they lack common sense and criteria.
> FizzBuzz is useful only to weed out perhaps the lower 5% of the developers population
Problem is, that 5% represents way more than 5% of the pool of job applicants, since it's those folks that continuously get rejected from jobs and keep applying. Any company hiring developers needs a decent FizzBuzz filter to sort out this riff-raff.
> There is no place for a FizzBuzz once the company is already engaging
In a technical and sharp company, yeah. In a company where the resumes go through HR and nontechnical managers, such that the first point of any technical evaluation is in the interview itself, then yeah that interviewer is going to need a FizzBuzz. And this is distressingly common in companies who hire some software developers but whose primary domain is not technology, like medicine or shipping or education.
Fizzbuzz is an analytical problem, not really a programming problem. A kid with no knowledge of a particular programming language could create an algorithm for it with a little guidance.
"Are there any patterns in this that we could use to make this shorter?" , "You're printing 'fizz' more than once. Is that necessary?", etc.
You're looking at the wrong side of the meeting. It's the time before the meeting, not the time after.
I like morning stand-ups, but a big problem is that if the stand-up is at 9, I start winding down whatever I'm doing around 8:30, and I don't start new tasks after 8-8:30. Multiply the loss by the entire team every day and that's potentially a big loss of time. And because everyone's schedule is different, there's really no place to put the meeting that avoids the problem.
The benefits of a well-run standup can outweight this productivity cost, but it's a real cost that needs to be considered.
Has anyone ever tried an end-of-the-day standup? Would not tend to disrupt flow, because you're going home afterwards. Also might help keep the gathering focused and on-topic.
I guess this does presume that everyone wraps up at about the same time every day, which I've generally found to be the case, but may not work well with widely distributed workers or places where people actually practice a wider range of work hours.
I have seem teams use end of day stand-ups. The problem with those is that they tend to devolve into status updates pretty quickly.
Team members report on what they did that day, but seldom think about the things they are going to get done next and the things that are preventing them from getting started on the next thing, which in my opinion, are the more important things to focus on.
A team I interned with did standups at the end of the day but honestly, at that point, you just want to go home; you don't want to stay to hear what's going on with everyone else.
Families who won the lottery reverted to the mean in a generation or two
A small event known in the US as the Civil War, which completely decimated the economy of Georgia, just might have had something to do with this.