Ask HN: How to avoid giving a scathing code review? - <AUTHOR> For the past several hours I've been struggling to unravel a pull request from a newly hired coworker. It was apparent from a quick glance that it needed some work but I underestimated how bad it was. The main logic is in a monolithic ~400LOC function (in a dynamic language, not verbose Java or C) consisting of a deeply nested if/else spaghetti code. I wouldn't dare touching it with a 10 foot pole without tests but fortunately there are some and the original test coverage isn't bad. So I've cut it down to almost half the size so far but there's still way to go until it reaches a somewhat maintainable state. I've also found and fixed a few bugs along the way so strict refactoring is not even a goal at this point.<p>So I'm wondering how to go about this. A few code review comments here and there won't cut it. If I was to be brutally honest, I'd outright reject the PR and tell him to rewrite it from scratch in a clean way but that's probably not the ideal response. How do you deal with situations like this? <comment><USER3> What's wrong with giving exactly that feedback? "The main logic is too monolithic and deeply nested. Please refactor in a more maintainable version, split into several simpler methods".

Unless there is some politik behind your question, I see no reason to say exactly what you feel. I have given (and received!) similar reviews many times. Btw I don't think is useful to do the rewrite yourself in the review: you are robbing the original author of a chance to redeem him/her self. I also think that refactoring a complex function is not a "rewrite from scratch", and even a rewrite from scratch on a second iteration is seldom as time consuming/complicated as the first iteration.

If you or your coworkers shy away from giving honest feedback in code reviews you have a big problem. Lowering the bar leads to technical debt grow, which someone will have to deal with later. You are missing a great opportunity to educate (and learn from) your peers.

If your managers pressure you or your coworkers to "go easy" on the quality (ie. "It works, let him check it in!") then again you have a big problem. You trade immediate achievement for later pain. It may be because is their immediate achievement but somebody else's pain later, and in such a case you're in a bad environment and not much you can do.

If you personally want to avoid the friction of a review that is asking for a major rewrite, you can sugar coat it, but ultimately giving negative review (when warranted!) is part of your daily job. As long as is objective and arguably leads to better code (and behavior) it should offend none.

Keep in mind that we all often write the code in iterations, and once is working we feel an urge to push it out without taking a break and looking over it again, but you the code reviewer see directly the end result. If is not pretty, is not necessarily because the original author is a bad programmer. It may simply require to take a break and have a look again, and he may see the same problem are obvious to you.

<comment><USER4> > What's wrong with giving exactly that feedback?

Giving feedback on a code review is really meant to improve small bits here and there. Incremental improvement. If someone doesn't know a new language construct, a better way of doing things, etc.

If someone simply writes crap, telling them that they wrote crap isn't helpful ... because they're clearly incompetent and are only capable of writing crap.

> If your managers pressure you or your coworkers to "go easy" on the quality > (ie. "It works, let him check it in!") then again you have a big problem.

This is really the issue. First, you'll piss off the incompetent coder. Second, you'll stall the project. Third, you'll piss off your boss, since he's probably the guy who hired the incompetent coder.

All the while, you're "making waves". All based on what is essentially your opinion on what clean code should look like. Because it _does_ run.

I would just take it slow and incrementally target some of the worst offenses. You'll never make the guy into a competent developer, but you can at least ameliorate some of the worst offenses and improve the quality of the code.

If you're actually working on the codebase as well, instead of just reviewing it ... I would talk to management. Explain the situation. They're either going to fire the new guy or you're going to need to find another job.

One of the reasons I like freelancing is that I don't have to face these dilemmas. The next client is just around the corner.

<comment><USER5> "Reprove with sharpness, then show afterwards an increase of love."

Telling a coder he needs to break down a function and get rid of deeply nested function isn't calling it crap, it's giving him a way forward to improve his code. As a new hire, he deserves that feedback. If he follows it, compliment him and give positive feedback.

Whether a person can become a good coder isn't determined by how he writes code, it's how he reacts to the feedback he gets. If he can take correction, he can become a good coder.

<comment><USER6> > Whether a person can become a good coder isn't determined by how he writes > code, it's how he reacts to the feedback he gets.

Quoted for emphasis.

My first recursive postgresql function was crap. I recently learned that it became a DoS vector at 3 layers deep because I had horribly flawed logic. I spent an hour the other night refactoring it.

The cruelest feedback comes not from mortals, but from the harsh production environments which do not tell you what is wrong, but merely go offline.

</comment></comment></comment></comment><comment><USER7> If the code is that far off the deep end, then your job at this point needs to shift from code reviewer to teacher.

You need to patiently explain not only what is wrong, but also why it's wrong, and how to fix it, with examples. You might want to even sit down and refactor the code with him.

You need to explain the code design concepts and principles that he has missed. In short, you need to GUIDE him.

It's either that or get rid of him, because until SOMEONE teaches him, he will continue doing what he's doing and remain oblivious.

<comment><USER8> > teach him

it's more important that he learns how to find better ways to do things himself. I would ask him if he thinks it's actually check-in worthy. I would continue asking until his doubt about it got the better of him, so that he views his code with a more skeptical eye. Then I would ask him to come up with 3-5 succinct ways to improve this. If they were good, I'd have him implement them.

You don't do the work for them, and you don't show them. The point of the college degree is that you've learned how to teach yourself without handholding. You need to be able to craft creativity yourself from blocks of wood.

If the 3-5 improvement ideas were bad, ask him to try again. If he still screws up [which is unlikely IMO] (and is really trying to come up with good stuff), give him one idea, ask him what he thinks of it, why, etc; have him implement it, give him another, etc.

<comment><USER9> The techniques for writing well-structured code may seem obvious to someone who has been practicing them for a long time, but they may be not at all obvious to someone who is just starting out. After all, it took a few decades in the history of programming and some very smart people like Dijkstra to convince professional programmers that code structure was important. The principles of refactoring weren't well known until much later. So I think that expecting some junior programmer to come up with these ideas by trial and error is setting them up for failure.

<comment><USER8> this is a very good point.

my own experience writing C was basically that all the fancy terms in the book didn't help me any, because they translated poorly to tacit knowledge. what helped me was running into the problems myself, coming up with the solution myself, and then realizing someone had already done it.

I'm very slow at tacit acquisition though. I needed more practice. For someone like me in the first year and a half, I would just give them the info. However, now that I have 3 years of C and C#, I can rapidly digest new design paradigms, and write much better code. If the guy purported to have 5-10 years of experience and is still writing crap, I would take issue with telling him the problems himself as he's probably one of those rote-memorization dudes that China or India pumps out with no tacit understanding.

</comment></comment></comment></comment><comment><USER10> This sounds like a mentoring rather than a code review situation to me. Code review is a look at code, judging its general applicability (usually a pass, in this case apparently not), commenting on style and/or obvious bugs, test coverage, suitability for deployment and so on. You try to stay civil and constructive, guiding the submitter towards what you would have liked to receive in the first place, you gently reject the PR with a list of 'tofix' items.

Wholesale refactoring (especially by you, really, do not refactor someone else's pull requests, teach them what you want to see instead!) and/or wholesale rejection quickly degenerates into an impromptu performance review or even a question of suitability for the position. If you plan on keeping this person around I'd argue for assigning a more experienced 'buddy' to this person who will be on the receiving end of the reject (as the more senior person) after which they together will engage in a do-over according to your local practices with respect to all the things you feel are wrong and/or questionable.

This will take some time. Essentially this person should not have been in a position to submit this PR so the failure is a process and a management one, not one of that particular employee.

<comment><USER11> responsibility for the failure does belong to management, certainly, but taking away all responsibility from the employee for producing poor work is amazingly populist, but not particularly helpful to the reality that the person is unable to do the job assigned.

I'm assuming such this is some of that good old low-current class warfare you get in tech circles... all managers are stupid and evil, all engineers are pure and virtuous. that's the same sort of thing that leads to Aaron Swartz being lionized for breaking the law, because the prosecutor sought a ridiculous punishment.

a failure in process does not have the side effect of absolving individual responsibility.

<comment><USER10> The guy simply should not have been in a position to send this PR, that's not populist, it's reality. So you fix the process and you try to salvage what was produced in a way that has the least overhead and the maximum possibility for success.

If you feel like pushing the blame on the employee you can do that but then you risk it happening over and over again, in the end the employee owns the code he produced but the process that put him in that position is 100% a management issue.

The trick is not to either define this is good old low-current class warfare or as stupid or evil managers and virtuous engineers, that's a total strawman. You simply need to apportion your effort there where you can fix what went wrong and to avoid a repetition. Aaron Swartz need not be brought in to it, that has nothing to do with any of this.

</comment></comment></comment><comment><USER12> You could simply go ahead and give the scathing code review, if you wanted. I used to work with a few senior engineers like that who were extremely sharp and, shall we say, point-blank with their feedback. But their feedback was always about the product, not myself, and they often provided guidance outside of reviews. After some initial butthurt, it teaches the young engineer to learn to separate their identity from the product they've produced.

Or you could couch your feedback in mamby-pamby happy-land that said programmer still deserves a trophy for trying. I personally am fine with someone saying "this block of code sucks" if there's an unarguable set of reasons/metrics attached to that statement. Usually better if the reasons come before the conclusion. Avoid style preferences or bringing general identity accusations like "all _your_ code sucks" into the review.

Keep the focus entirely on the product not the producer and that's fair game. Maybe tell the newly hired coworker a story about your code once used to suck, and how you overcame that.

<comment><USER13> Or you could avoid the fallacy of the excluded middle: list in a clear and objective way exactly what is wrong and (if applicable) points to fix it. "Sucks" is a subjective comment and not very useful feedback. I know my code sucks but not why it sucks - that is partly why it is being code reviewed.

<comment><USER8> > fallacy of the excluded middle

wordy synonym for false dichotomy?

<comment><USER10> No.

       X --- excluded middle --- Y

Versus

       excluded left bit --- X --- excluded middle --- Y --- excluded right bit

</comment></comment></comment></comment><comment><USER14> This is why pair programming is so great, especially when the duo is somebody seasoned and a new hire. Pairing is continuous code review so you address problems like 400LOC methods before they start. It also reduces the newbie's sensitivity/fear/hostility to feedback when the code is your shared work product. "How could we make this better?" feels a million times better than "You should have done it this other better way".

I'd definitely give it a try, at least for onboarding new people. There's no better way to transmit knowledge about the code and expectations for how to work with it.

</comment><comment><USER15> I wouldn't deliver a scathing code review even though it would probably make you feel better, at least for a little bit. Instead, I'd approach the person and see if they misunderstood the task, were overwhelmed etc. Approach it from a teachable moment first, if a pattern of behavior and bad code continues then address it with increasingly direct feedback.

I state this because I have done the opposite and it can backfire in ways you don't initially think. So I have learned it is always best to start of with an inquisitive mind on why he/she wrote it this way and what were their instructions and then use it as a teaching moment to help them be better.

I have seen companies where people got rewarded for the most convoluted stupid ass code you can imagine, generally in larger enterprises. As an example, I all but stopped hiring financial services programmers in the late 90's early 2000's in my area because we found we had to get them out of so many bad habits. Not saying all were bad, but our screening of someone anytime I saw financial services (especially big banks) on their resume as a developer was quite a bit tougher. Its not quite the same today, but I still know teams that I wouldn't hire from without really screening someone heavily.

Also, I guess one other point. If this person was hired at a senior level vs a junior or mid level, I would still approach it the same but be more critical (and direct) why they would write code that increases the likelihood of defects.

</comment><comment><USER16> tl;dr Don't try to fix the code, try to fix the process that produced the code. This is an opportunity to encourage and teach, berating will produce the opposite result.

Telling someone they are stupid is the most effective way to have them not listen to you. I would approach the situation along the lines of this:

1) This is a really good first pass. Thanks! I like how you... 2) Lines x to y seem a little messy, do you think there is a more elegant way of approaching this? (Note: y - x < 20) 2b) Maybe highlight another area for improvement? 3) What happens if the feature requirements change? Can you show me how we would adapt to that? (Response: Oh, I see. Nice. Hmm...I wonder if we treated this in a more abstract way, would it require less maintenance?) 4) I'm really excited to have your enthusiasm (or other personal trait) as part of the team. Let's go get this!

Why I would use that approach: 1) Sandwich method is a classic strategy for giving negative feedback (positive then negative then positive). It minimizes defensive and emotional reactions. 2) Do not attack the person in any way. They will get defensive and angry and insulted. They will not hear "this is how I can improve" but rather "they are out to get me and not to be trusted". Humans need a sense of safety. 3) It's very possible that they are overwhelmed and scared at this new job. Insulting them will not build confidence, but rather destroy it. 4) It's also very possible that they've been trained to write crap as fast as possible, commit, and move on. If this company has a different style, they deserve to know that.

I would also want to know how did such poor architecture get implemented. It might be good to have design reviews, before coding starts, to discuss how everything should function. It sounds like the bad code is partially a result of improper communication with the employee.

Great question!

<comment><USER8> > It's very possible that they are overwhelmed and scared at this new job.

from personal experience, biggest reason

</comment></comment><comment><USER17> I'd basically say:

"Before I accepted this pull request, I would ask you to do a lot of refactoring. However, it's too complicated to explain in comments on the diff. Why don't we sit down and fix it together?"

Then explain your reasoning for the overall changes and each smaller change face to face in a pairing session (or series thereof).

<comment><USER18> Agreed: this is now an in-person conversation where you have an opportunity to help your colleague grow.

I have to say that I find it odd that you spent any time at all re-writing this person's code. If I was your manager, that is not what I would want you to do.

Further, reviewing code over 400 LOC _total_ is generally a waste of time (never mind a single method larger than that.)

</comment></comment><comment><USER19> Others have mentioned it incidentally, but I'll highlight it:

When you're at this point, talk to them offline, either face to face, video conference, but somewhere privately. The core message should be that the code is sufficiently convoluted that you can't effectively review it and you think there must be a better approach. Comprehensibility is always a code review concern, so you're on solid ground there.

The big thing here is that there's a point where the honest code review will basically be "wow, you screwed this up big time," at which point doing it in front of other people will make things worse and not better--your coworker will probably dig in their heels and will definitely feel humiliated enough to not really be open to constructive criticism. Comes down to the whole criticize privately/praise publicly thing. It's not about politics, just human nature. And as much as people should be able to take a critical code review, taking one that effectively says you bungled the entire thing requires rather superhuman objectivity.

Unlike others, I'll say that you don't have to turn this into a teaching or mentoring moment unless you're the lead and that's your job. If you want to do so, great, but that can be a lot of load to add to what should be a straightforward task. It would be good for you to be able to articulate in neutral terms some of the issues that make the code incomprehensible. You can even get a sanity check and maybe a few ideas from a trusted colleague.

Your best outcome here is a followup comment _from your coworker_ saying "after offline conversation with reinhardt, I decided to rework the code and will resubmit."

</comment><comment><USER20> You gotta find a way to figure out if this person is CAPABLE of delivering better code. That's gonna hinge on their talent, and their willingness to learn. At some point, some folks make it clear, one way or another, that they can't/won't get much better, at which point you unload them.

Until then, you need to be friendly and patient, for a number of reasons. Don't betray shock, and don't betray disbelief in their incompetence, but do firmly require them to sit through a lengthy code refactoring with you or someone you trust, so that they can see what is required AND how far their code is from what is required. They need to feel your pain, but not by you being testy or edgy or frustrated.

Or, as the good writers say: show them, don't tell them.

<comment><USER21> That was my worry: the guy who writes 400 line functions/methods/subs is always gonna do just that when nobody is looking.

I am assuming 2 to 4 years training or education prior to this. If you haven't learned to subdivide long / deeply nested routines into smaller functions with defined inputs and outputs after 2 years, you probably just don't get it, and may never.

That seems harsh, I suppose. But I've been doing this for a living for most of the last 30 years. When I started, I was 2 years into my CS degree. I've met too many code monkeys who might know some new API, but just congenitally cannot organize code to save their lives and write stuff I would not even have written as a 20 year old part timer going to school.

Spend a few weeks to see if the guy can learn. If not, start documenting a "performance improvement plan" (there's a euphemism) so you can get rid of him.

</comment></comment><comment><USER22> As the code _reviewer_ you should probably not be doing any writing. Instead, you should _send back_ the code with notes. An in-person meeting would be better to go over the changes.

Teach a man to code, he can write crappy code. Fix it for him, he still writes crappy code. Make him fix it himself, he learns (hopefully).

Also, as a code reviewer myself, this is really difficult, but the best way to fix this kind of thing in the future is to get involved in the code much earlier on. Watch the commits as they get made, stop by occasionally and go over the code while it's in progress. If the guy spends a week working on something and you send it back, he basically wasted a week. If you can spot a problem within a few hours, then you saved both of you a week...

</comment><comment><USER23> This is not a direct answer to your question, but might be relevant nonetheless.

What I have learned is that having automated tools that enforce your code style and measure code quality (e.g. Code Climate, rubocop in the Ruby world, jshint etc.), integrated in your test suite or CI, goes a long way in improving the quality of your PRs (and, of course, code in general).

There's a cognitive difference between reading a code review written by a colleague and having a set of rules that are simply enforced automatically. This might matter a lot for new hires who have yet to learn that code reviews are about getting better and learning new things (and not about highlighting mistakes). Of course this wont replace code reviews, but it might remove some friction.

</comment><comment><USER24> This is a great opportunity to pair program with this person. You have the advantage of knowing the codebase and the company style/nuances. Sit down and show him. Don't point the things that are wrong. Make a list if all the functionality required and then read line by line or chunk by chunk. Write code and tests as you move along. Let him write it but you take lead on how. Ultimately, step on his shoes. It's the worst feeling in the world when someone says you wrote shit code. Don't make him feel shitty. Make him feel like he is part of a growing team.

</comment><comment><USER25> You can be honest with them without bringing up things that aren't relevant. There's a reason you don't like the PR: it's too big, it has a lot of conditional logic, etc etc. There's a bit of personal dislike with it, but that dislike is also founded. There's increased complexity, which makes it harder for others to understand, and most likely harder to test. It comes out as a personal feeling of "ughhh" when you look at the code, but there's an objective component to it that, if you take the time to, you should be able to get across.

Everyone is different, and I certainly don't know all of the right words to say, so I'll simply say what I think should be mentioned no matter what: point out the problems with the code, not the person. "What if we broke this apart in two right here? It looks like it'll be hard to test this in isolation otherwise." "What are your thoughts on some sort of pattern matching / switch statement here instead of using if/else blocks? Any downsides? Might end up being a little cleaner."

You're trying to make the case the code can be better, but not that it's horribly bad. I mean, if it works, but it's ugly, you have a base. They got the job done. Now it's time for you to help them make it better.

</comment><comment><USER26> I don't have enough information to give much advice.

        - Is the programmer Jr or Sr level?
        - Are they new to the language?
        - Are they new to the architecture/style?

Obviously spaghetti is not acceptable. But if they are a beginner, then you have an opportunity to be generous in your review and help teach them (as you should for beginners). If they are senior level and they should know the language then it may be a sign that it was not a good hire.

</comment><comment><USER27> I've had this happen before, and the code review was met with resistance -- ultimately the person on the team least able to design modular architecture was given perhaps one of the most critical architectures to design, and it was more difficult because management gave him the task because everybody else was busy with other tasks.

It can be difficult. Somes some people aren't _meant_ to be developers, but ultimately you need to foster a good culture of software craftsmanship.

If you have the same manager, I'd see about talking to them first about how to approach it.

If you don't, you are in trouble.

Hopefully, this person wants to learn how to write better code.

Now, the opposite is also true, it sucks to be on the other end, and sometimes the person reviewing is on a high-horse and possibly _wrong_ as well. A 400 line function does seem wrong, but just because you're not using someone's favorite Ruby function or not writing all 2-line methods doesn't mean that is wrong either.

Code is intensely personal - engineering rigor is required,b but personal style and creativity are vital to enjoying the job as well. This can be very hard in group contexts.

Perhaps it would be possible, if you're on good terms with this person, to set up a pair refactoring session where you start to unwind it?

I think it's always easier to do things while things are being designed, rather than to do something at review stage, where it more feels like things are being judged.

I always like to encourage folks to talk about code as it's being written when I can.

<comment><USER28> I've been on the receiving end of several code reviews that could be summarized as "You didn't write this exactly the same way as if I had written it." This was at places that did not have uniform written standards uniformly applied. It was just the boss swinging his dick.

</comment></comment><comment><USER29> Code that I've seen like that is usually an organic method that grew to meet additional requirements and edge cases.

This seems like a great teaching moment on how to break up 400 LOC into smaller, more understandable modules. I would encourage you to block out some time with the dev to pair program and refactor it. If you refactor it yourself and then show them, they'll never learn how to do a better job in the future.

<comment><USER30> I think refactor and show them could help them learn.

No need to be that pessimistic is all I mean.

Pairing would be better.

If the employee does not have time to pair, I would still do the refactor and ask the boss how much time they will be given to review the changes (I would assume/expect they would be given many hours to do that, if it took many hours to refactor) ....

</comment></comment><comment><USER31> I'd focus on the distant goal: Getting this coworker to make higher-quality contributions in the future. (Which helps him/her in their career just as much as it helps your project). In that light, I think it's doing them a favor to be honest. Refactoring their code for them (cleaning up their mess) isn't really teaching them much, or setting yourself up for anything but a repeat of these events. In your position, I'd probably reject the pull request and give them a handful of pointers/things-to-work-on.

You don't have to mean about it, just be straightforward and make sure you're only addressing the inadequacies in the code itself, not attacking them as a person. I'd try to convey this message (in your own words): "I appreciate the hard work you've done. That being said, I think you're a very capable programmer, so I'd like to see you push yourself even harder. If you were less-talented I would accept the pull-request, but I'm betting that we can get even higher quality output from you."

</comment><comment><USER32> First, be polite. Actually, I've found this to be a useful mantra for all things business-related.

Next, realize that if it works, the developer may consider it done. Many organizations don't see maintainability as an important goal and stop at functionality.

So, with those two things in mind, I'd suggest to the developer to keep functions small (do you have a coding standard?). Show him how the logic can be refactored (a surprising number of good developers never think about refactoring).

Next, consider that you may be imposing your personal preferences on him. Does your team as a whole generally follow the practices that you are telling him? I find that this can be a difficult topic in code review: of course I want everyone to do things the way I do them, but I have to stop short of trying to create little "mini-me's"

tl;dr: be nice, point out how the rest of the team codes, suggest a rewrite based on the concepts you bring up.

</comment><comment><USER33> I'd recommend ignoring Maratd's advice.

I used to be a horrible coder. I used to have just the issues you describe here. I wrote spaghetti code, I didn't understand objects and classes properly, I probably had every bad habit in the book.

I kept getting noticed as a 'good programmer' because I did stuff other people didn't get. I was good at figuring out the puzzles how to make pieces fit, but I was, quite frankly, a bad coder.

I got a contract for a big company, and I wrote the app they wanted. The code was awful, but I didn't know that. When I finished the contract and passed the app over to their IT division, it went through a 'code review' process.

I'd like to be able to tell you that the CTO pulled me aside and told me what was wrong with my code. Had he done that, I would have taken back all my work and refactored it for them so it was well written. But, of course, he didn't do that.

If the CTO had taken the time to explain to me why my code was bad, I would be very grateful for the learning experience. I would look back on that time as a defining moment which sent me on my course as a professional software engineer. But he didn't, so instead, I gradually, over the course of a few years, learned what it meant to write good code.

I probably lost my first coding job because my code wasn't great, but it could have been, had somebody taken the time to explain to me why it wasn't good.

So, I hope you can look at this not as a time for a 'scathing code review', but rather as an opportunity to help a struggling coder to maybe become excellent.

I think the most important thing may be to NOT do the work for him. Stop at what you've got so far and you can use it as a comparison, so he sees what the difference is between what you did and what he did.

Then let him take another shot at it. If he doesn't want to redo it, or thinks he can't, then you'll know he's a bad employee and a likely not going to grow to become a good coder. If he jumps at the chance and is eager to learn, you'll know that he might have a shot at this.

Do make sure you go through your HR process (if you have one) of recording the poor performance though. But let him know that you have to do that just so that the company isn't stuck with him if he isn't able to adapt. But if this is approached properly, it may be the best gift you could give the new hire.

</comment><comment><USER34> I work with a lot of contractors and so I end up doing this frequently. Here's the pattern I follow:

1\. Reject the PR. It needs to be clear that this isn't acceptable. 2\. Realize that stopping with rejection doesn't help the problem at all. :) 3\. Start with some light comments and refactoring a couple of sections (usually it's the same bad patterns repeated). 4\. Only provide the refactors as comments. Try not to fix other people's PR and then submit. It makes it hard for that person to improve. 5\. Talk with the individual about it. Ask about the issues they were having and offer fixes. 6\. Ask them to try again.

If this cycle happens a few times, you either need to break down tasks into simpler, smaller bites, or let them go. This can quickly turn into negative productivity for the team.

</comment><comment><USER35> Try separating out the factual observations from how you feel about them. "The main logic is in a single ~400 LOC function" is a simple observation and less likely to make your co-worker feel attacked. I think the word "monolithic" is counter-productive.

"I noticed that the main logic is in a single ~400 LOC function. I'm concerned because I may need to make updates to this in the future, and larger chunks of code are harder to work with. Would you be willing to pull it apart into smaller functions?"

I think that "I wouldn't dare touch it with a 10-foot pole" is something that I'd leave out of the PR comment. The observation that it is complicated, and the concern that future work on it would be difficult, that can definitely be included.

</comment><comment><USER36> [http://xkcd.com/1513/](http://xkcd.com/1513/)

Treat this as an education opportunity, one that can be used to mentor the new hire. Just having her/him rewrite the code from scratch will not help prevent a repeat of the problem.

</comment><comment><USER30> Keep doing what you are doing in refactoring and fixing it. Spend hours on it. Tell the person you spent hours on it. Tell them you expect them it will take them longer, but these are the standards you expect of yourself.

Ask your boss / their boss if they also expect those standards or if you are wasting your time or if this was a good use of your time to spend hours/minutes rewriting this employees work. Ask if that employee should be spending 2x/3x/4x the amount of time on their code to get to that level.

edit: What I mean is, it doesn't sound scathing if it's helpful. Scathing does not have to be in the vocab. Just be helpful to everyone, coworkers and superiors. Everyone wants to do the right thing.

<comment><USER10> I'd really counsel against refactoring and fixing it, that is not what code review is for, you review, comment and return and leave the refactoring and fixing to the submitter (see above for a more comprehensive solution).

If you insist on refactoring and fixing all the PRs you end up being the bottle-neck, and your co-workers will not learn as much from the experience as they could.

<comment><USER30> I can see the point on being a bottleneck.

I'd still argue that's probably a good bottleneck to have though, and certainly better than letting the code quality slip. It depends on the timelines and priorities, but I'd rather work somewhere that invests time up front to save time later.

I strongly disagree that the co-workers would not learn from said refactoring. That's very pessimistic on either the coworkers reading comprehension, or pessimistic on their attitude or willingness to engage with the changes without being forced to do so? I don't know I find it amazing when someone offers a refactor suggestion, whatever amount of "doing it" they do for me, I find I learn a lot from learning what the changes actually are. If they do it themselves I get a really good feel for their style and what I can learn from it.

edit: And on the flip side, I find it's sometimes faster to just make a small refactor change than to explain it in person --- but this depends on the physical locality of teammates and schedule conflicts. In other cases it's easier to swivel the chair around and poke them on the shoulder and explain the refactor than to make it. Which is easier depends on priorities, chain of command, schedules and all that.

</comment></comment></comment><comment><USER37> I like to follow 3 simple rules.

\- Don't phrase your feedback in such a way that you wouldn't feel comfortable saying to this person's face, or have read out in court. In other words, be professional.

\- Mark each piece of feedback as "Blocker/Not-a-Blocker", to cover issues which (in your opinion), need addressed before using or are simply opinion points which are at the author's discretion on whether to use.

\- If you know of a better way to write it, include a snippet or some pseudocode if possible. If it's more complex than a snippet and it's a work situation, then write your point succinctly and then approach in person and offer your assistance in pairing if they would like.

</comment><comment><USER38> I never had to give a _scathing_ code review but every time I had to give one with a lot of requests for changes I would always point out why I'm making each request - with links to style guides, articles about code quality, code smells, best practices etc. There are also automated tools that can do some of that for you (codeclimate.com comes to mind) so that you can delegate some of your 'work' there.

BTW from my experience teaching people to avoid nested control flow is one of the simplest things to do - just show them how many different code paths are possible (and how many tests would be required to cover each one) in a function with 4 nested if's.

</comment><comment><USER39> New hires need to be onboarded properly - specifically, you need to set expectations quickly. Having a place (like confluence, or other wiki) where these are documented is a good start (so you can later reference them) - <USER2> simply put, you should sit down next to this person, and help them to understand how, but more importantly, WHY you would suggest certain changes. Take the time to build trust with this person. Make sure, at all costs, that you come from a place of helping / teaching - dont come across as an ass.

</comment><comment><USER40> Reject the pull request, but be civil about it. Explain what is wrong with the code and give some pointers for fixing it.

I suggest you do this in person. Rejecting someone's work can easy come across as maligning their skills in general, particularly in print. It will be easier to make the distinction face to face. This will also allow for more discussion of what changes are needed, if your coworker has questions.

</comment><comment><USER41> Before you do anything, please look into this kid's (?) mental state and try to gauge how hypersensitive he may be to being critiqued.

As you said, he's a newly hired coworker. I think the last thing he wants is to be "outed".

If I were you, I'd offer some explanation as to why you want to reject it, and then offer to start him on the correct path.

</comment><comment><USER42> You are already going about it the right way, by doing two things: 1. you are specific 2. you are investing time to offer a better way.

A good way to communicate is to keep it informal and provide direct feedback, w/o involving anyone else, so you avoid making the developer feel inferior or feel that there is a political element involved. Ideally, you would share screen and code the suggested improvements together, and it will not only help you accomplish what you set out to do, it can also build a bond/trust/respect between you and your new colleague.

During the conversation, I would try to understand the following: Is there any legacy, currently working code, that has been implemented in this monolithic approach? Maybe the developer realized it was ok, for the initial iteration. Is the developer under a tight deadline? To meet the deadline she prefers solving problems in this way, for the initial iteration. In both situations above, the developer is aware of a better way, and your help to get it there in time will be appreciated. If not, some coaching is required (hopefully you have coding standards to refer to): Is she interested to learn a better way? What are her reservations and counter arguments?

For smaller teams, daily team code reviews are very helpful.

Have fun!

</comment><comment><USER43> If you're already weeding through the code, why not invite the coworker to sit down next to you? In my experience, sometimes all someone needs is a pattern to adhere to, and once you show that pattern things might work out.

Of course, this is only good about 80% of the time. Sometimes people just don't get it.

</comment><comment><USER44> > A few code review comments here and there won't cut it. If I was to be > brutally honest, I'd outright reject the PR and tell him to rewrite it from > scratch in a clean way but that's probably not the ideal response.

I disagree, that's exactly the ideal response.

</comment><comment><USER45> Do you have code standards that state maximum function length, what "clean code" looks like, etc.?

If not, then that ought to be a priority, so that you can point people at that in the future, when rejecting pulls.

</comment><comment><USER46> Pair programming pretty much eliminates this issue</comment>


Sexism in the tech industry - it's not just the guys - <AUTHOR> http://typespace.co/13-Sexism-in-the-tech-industry---It--39-s-not-just-the-guys

<comment><USER2> "What About The Men!" cries a man who takes insult at the idea of a space he isn't welcome. An exception to the rules of society!

And his point about all-woman hackathons is kinda refuted by his own banner image. A room full of men with three women. People don't like feeling exposed and isolated. Just maybe if events weren't a super-majority of young white males then minority groups wouldn't need to create a safe space for themselves to not feel like outsiders.

To that the brave Male Rights Warrior says "Well people are just people! They should just get over it and fit in." Well they are getting over it, by hosting their own events where they feel comfortable. You just aren't explicitly invited.

<comment> jack-r-abbit I think it is less about taking insult at the idea of a space he's not welcome and more about taking insult at hypocrisy that seems to be around the "It is bad when YOU do it. But not when we do it" type of stuff. The equality that is being sought is not really a true equality. That's my 2 cents.

<comment><USER3> But that's not really true. If equality is achieved, there's no need for such "safe space" events and they'll likely disappear. But at the moment we are far from equality, so there is a need for it.

<comment> jack-r-abbit So until this all gets sorted out, you'd be fine if an all-male event was put on so men could feel safe from being publicly shamed by an overreaction to overheard comment? Everyone has an equal right to feel safe, right?

<comment><USER4> Yes, they do. It's just that Men have no reason to feel unsafe, because they are in the majority, Indeed, the large majority of coding events, seminars, lectures, terminology, etc - are geared towards men. This is the same argument as someone loudly asking "Why isn't there a White Entertainment Television channel?"

There is. It is every other channel on TV, where the default assumption of an audience member is a white (and typically male) human in their 30's. We have no reason to feel unsafe.

<comment><USER5> "Men have no reason to feel unsafe, because they are in the majority"

Prey animals don't share your optimism. They live lives of eternal vigilance. To a gazelle, the price of failure in vigilance is death.

In a world where it is increasingly becoming more dangerous to step out of line. Racist, sexist or otherwise offensive jokes will cost you your job, regardless of how "safe" you thought the joke was: it only takes someone to interpret the joke as offensive and report it to an authority, and you end up out of a job.

The person taking offense is the lion. The person unwittingly causing offense is the gazelle who let down their guard for five seconds.

Men have every reason to feel unsafe: because they are in the majority (in certain environments) it is easier to assume that a particular joke will be acceptable to any gathering. The more people are in hearing range of that joke, the more likely it is that someone will regard it as offensive and take disciplinary action.

The price of freedom is eternal vigilance and continual self censorship.

</comment></comment></comment></comment></comment></comment><comment><USER6> This Lulu thing _is_ fairly controversial, judging by App Store reviews. A previous attempt to do this moved away from posting reviews of men: <http://en.wikipedia.org/wiki/DontDateHimGirl.com>

<comment><USER7> Not to mention their possible trademark infringement, as there's already a book self-publishing company with the same name: <http://www.lulu.com/>

</comment></comment><comment><USER8> The problem with this line of argument is that while technically correct, it completely lacks the context that underpins the entire _problem_ of discrimination against women.

Men discriminating against women is a problem because of the _effects_. The lesser rights. The lower pay. Being passed over for advancement. The dismissive treatment. etc.

Until men are being systematically disadvantaged by the discrimination they receive from women, trying to equate our hypothetical hurt feelings at being excluded from the tiny minority of women-only events, to their very real career barriers is just adding insult to injury.

</comment><comment><USER9> For anyone else who hasn't heard of it, this is Lulu: <http://www.onlulu.com/>

</comment><comment> jack-r-abbit It is a double standard for sure. But we are not allowed to talk about that right now. We're busy trying to solve the problems that women are having. We'll get to our man problems after. :/

</comment><comment><USER10> I'm surprised this "men's rights" trash made it to the front page.

<comment><USER11> this isn't at all about defending men's rights to have a site like lulu, it's about saying lulu is bullshit and we should call a spade a spade. It's not saying that sexism is OK or defending sexism against women, what it's saying is that yes there is a legitimate problem, but behavior that is diametrically opposite of anti-female sexist behavior is a faulty solution. E.g., those "all-female" hackathons are clearly bullshit, but things like Hack and Jill (fixed at 50% female, 50% male) are very cool.

</comment></comment><comment><USER12> Author: please remember that race and gender are just social constructs. I usually refactor myself into a Straight White Male when going to conferences, just to get along.

So far so good, but one day at the zoo I got distracted and turned into a panda by sheer willpower. After that it took a while to wean off bamboo leaves.

If you see anybody gnawing on a bamboo stick at PyCon, please _do not_ post any pictures on Twitter. Thanks.

</comment><comment><USER13> Mz pointed out one reason you might want a women-only event.

 _a good reason to have some "ladies only" groups is because of the way a lot of women behave around men, not because of the way men behave around women or because "men are all sexist pigs"._ <https://news.ycombinator.com/item?id=5272532>

</comment><comment><USER14> Yeah! White men have been getting the short end of the stick for too long! Preach it, brother!

We need male-only events!

<http://swiftstack.com/images/posts/pycon-paul-graham.png>

</comment><comment><USER15> Prepare for a deluge of "it's not wrong when WE do it."

<comment><USER3> The concept of a "safe space" isn't discriminatory, it is a reaction to discrimination.

<comment><USER15> The fact that it's a reaction to discrimination is irrelevant. It's the same act, just with a different target, and changing the target does not change any reasonable value judgment that can be made about the act itself.

</comment></comment></comment><comment><USER16> The simple fact that the author posted anonymously demonstrates two things: 1. Whomever wrote it isn't proud enough to put a name to it. 2. It's a problem enough to warrant anonymity.

<comment><USER17> I see another simple fact - the author does not feel comfortable posting his views under his name because he fears retaliation.

And that's a problem.

<comment><USER3> And why shouldn't he fear retaliation? The suggestion that women having safe- space events is sexist is outrageous.

<comment><USER17> I don't know if you are serious or are being sarcastic.

Assuming the former (rather sad state of affairs), this short interview with Steven Pinker should explain why a society where people fear retaliation for voicing 'outrageous' views is fucked: <http://www.youtube.com/watch?v=B0W9sSqeJnA>

<comment><USER3> Actually, nevermind. Sure, they shouldn't fear retaliation, I'm not quite sure what I was going for.

<comment><USER17> Cool :)

</comment></comment></comment></comment></comment></comment><comment><USER18> "Is that all you've got?"</comment>


English as a second language: Test results on the most fluent countries  - <AUTHOR> http://www.economist.com/blogs/johnson/2011/04/english?fsrc=scn/tw/te/bl/whospeaksenglish <comment><USER3> Israel wasn't included. Anyhow here's a copy of the main graph:

        Rank, Country, EF EPI Score, Level
        1 Norway 69.09 Very High Proficiency
        2 Netherlands 67.93 Very High Proficiency
        3 Denmark 66.58 Very High Proficiency
        4 Sweden 66.26 Very High Proficiency
        5 Finland 61.25 Very High Proficiency
        6 Austria 58.58 High Proficiency
        7 Belgium 57.23 High Proficiency
        8 Germany 56.64 High Proficiency
        9 Malaysia 55.54 High Proficiency
        10 Poland 54.62 Moderate Proficiency
        11 Switzerland 54.60 Moderate Proficiency
        12 Hong Kong 54.44 Moderate Proficiency
        13 South Korea 54.19 Moderate Proficiency
        14 Japan 54.17 Moderate Proficiency
        15 Portugal 53.62 Moderate Proficiency
        16 Argentina 53.49 Moderate Proficiency
        17 France 53.16 Moderate Proficiency
        18 Mexico 51.48 Moderate Proficiency
        19 Czech Republic 51.31 Moderate Proficiency
        20 Hungary 50.80 Moderate Proficiency
        21 Slovakia 50.64 Moderate Proficiency
        22 Costa Rica 49.15 Low Proficiency
        23 Italy 49.05 Low Proficiency
        24 Spain 49.01 Low Proficiency
        25 Taiwan 48.93 Low Proficiency
        26 Saudi Arabia 48.05 Low Proficiency
        27 Guatemala 47.80 Low Proficiency
        28 El Salvador 47.65 Low Proficiency
        29 China 47.62 Low Proficiency
        30 India 47.35 Low Proficiency
        31 Brazil 47.27 Low Proficiency
        32 Russia 45.79 Low Proficiency
        33 Dominican Republic 44.91 Very Low Proficiency
        34 Indonesia 44.78 Very Low Proficiency
        35 Peru 44.71 Very Low Proficiency
        36 Chile 44.63 Very Low Proficiency
        37 Ecuador 44.54 Very Low Proficiency
        38 Venezuela 44.43 Very Low Proficiency
        39 Vietnam 44.32 Very Low Proficiency
        40 Panama 43.62 Very Low Proficiency
        41 Colombia 42.77 Very Low Proficiency
        42 Thailand 39.41 Very Low Proficiency
        43 Turkey 37.66 Very Low Proficiency
        44 Kazakhstan 31.74 Very Low Proficiency

<comment><USER4> I find it very hard to believe that China is ahead of India, even if it's a few percentage points, especially given that there are enough people in India for whom English is essentially a first language or a parallel first language.

</comment></comment><comment><AUTHOR> There's a few more factors besides the ones in the article.

-Most of the languages high on the list are similar to English

-The countries don't dub movies. This has such a big impact. I learned most of my English from movies.

<comment><USER5> Finland is the odd one out in the language similarity thing. Scandinavian languages and Dutch are pretty close to English, but Finnish isn't even Indo- European.

<comment><USER6> Strictly speaking, in terms of grammar, Finnish is an Altaic language, like Korean and Japanese. However, in terms of vocabulary, culture and just about everything else, Finnish is closer to English. It has not just a great number of loan words (as Japanese does), but also cognates.

Possibly more importantly, Finland shares a common history and religious background with Europe. There are many, many idioms and ways of looking at things that stem from historical and religious influences. Grimm's fairy tales, for example, spread through Europe widely, but not through Asia or the middle East. On result is that while Chinese often has sayings with a similar meaning as English ones, their literal meanings are very different. In European languages, on the other hand, the sayings are often literal translations.

<comment><USER7> Please note that the theory that Uralic languages such as Finnish or Hungarian and Altaic languages such as Turkic or Mongolese are somehow related is highly controversial and not supported by the large majority of the linguicists today. Japanese is not even considered to be an Altaic language.

<comment><USER6> Actually the inclusion of Finnish was the error! Its inclusion is very questionable, but the language group was proposed by a Finn. That's why I misremembered (former lingustics/Japanese major here). The inclusion of Japanese, on the other hand has been steadily gaining momentum for decades.

Linguists whose focus is on Japanese generally _do_ generally consider it an Altaic language. This includes the most prominent, such as Marshall Unger (under the name Macro-Tungusic). The classification is still somewhat controversial, but I think it's largely for historical reasons. Local Japanese language scholars, who are not linguists, have traditionally subscribed to the view that Japanese is special and separated from all other languages. Modern linguists do not generally subscribe to that view, regardless of whether a proto-Altaic existed or not.

In any case the points about shared cultural, historical and religious heritage still apply. Finns learning English have far more of a shared cultural framework to work from than Asians learning English do.

</comment></comment></comment></comment></comment><comment><USER8> Singapore wasn't in the study because English is Singapore's first language. (Article mistakenly says that the reason is because it's too small.)

<http://en.wikipedia.org/wiki/Singapore>

<comment><USER9> Singapore has four official languages: Modern Standard Chinese, Standard Malay, Tamil, and English. The majority home language of most Singaporeans born around the time of independence was one or another southern Chinese language, with Hokkien being the most common (but perhaps not an absolute majority of the population). Also by no means all of the sizeable minority of Indo-Singaporeans were native speakers of Tamil at that time, but Tamil gained the designation as an official language.

The sole language of instruction in primary and secondary schools supported by public funds in Singapore since independence has been English, with most pupils studying one or more of the other national languages. Singapore shows the lie about excuses for poor educational progress in the United States. Many school officials in the United States whine about the diverse language backgrounds in some United States school districts, but nowhere in the United States do you have primary education being done with a population attending school in English but the MAJORITY of the population not speaking English at home, as was the case in Singapore just a generation ago.

I've heard some amusing stories from Singaporeans and from Malaysians of Chinese ethnicity about how to learn just enough Malay to pass school exams and then forget it. English is the language it is crucial to know in that part of the world.

</comment></comment><comment><USER10> Argentina was #16 overall and #1 in Latin America. As an American living in Argentina I think that sounds about right. Knowledge of English is definitely more widespread here than in other countries in Latin America that I'm familiar with, particularly in Buenos Aires.

<comment><USER11> Uruguay did not have enough data to be listed, but the years I took the Cambridge and Oxford language tests (FCE, Proficiency, etc.), Uruguayans were in the top spots (the #1 overall got a scholarship to Oxford, and she was Uruguayan).

Of course, the demographics very much the same as Argentina's so it wouldn't be a big difference (we're not an Argentinian province by political accident and meddling by Britain - not that we mind :) ).

<comment><USER10> I believe it. I know quite a few developers from there and aside from being quite talented at what they do, their English is excellent. But having spent little more than a weekend in the country I didn't want to assume they were a representative sample. :)

</comment></comment></comment><comment><USER12> Here is my take about Japan:

In Japan people learn English as a part of mandatory public education without targetting any practical use, and many companies mandate good exam score or certificate about English, even if they don't need English skills on the job.

This leaves Japanese in a strange parallel world of learning English, where the goal is scoring good and getting a nice job, not communicating with others.

Hence people without real incentive are forced to take globally standard English tests such as TOEFL or TOEIC, resulting in that low average score.

</comment><comment><USER13> The results are pretty much what you'd expect, really. English proficiency is largely a cultural given. Movie dubbing and such definitely plays a big part of this, as language is largely assimilated by listening to it. If you're taught English by a French person and you never hear anyone else speak English, well, you're going to be a lot worse at English than someone with a comparable education who has more access to spoken English.

It's a shame that the study only shows results per country, and not per language region in countries. For instance in Belgium there are three language regions -- Dutch, French and German -- and I'm willing to bet that the results in each region are much closer to those of Holland/France/Germany than this meaningless average.

The reason why English is rather hard for speakers of Asian languages should be pretty obvious: there is such a _big_ difference in sounds. The sounds used in English are _much_ closer to those used in Spanish than Japanese, even though English and Spanish are already miles apart..

<comment><USER14> > The reason why English is rather hard for speakers of Asian languages should > be pretty obvious: there is such a big difference in sounds.

I disagree. The problem is the grammar. Asian languages are rather "grammar- less" (not that such a thing is technically possible), at least compared to Indo-European languages.

English tenses in particular are hard for even continental Europeans to understand. I learnt German for awhile and Germans just struggle with English tenses. There are only a handful in Germans and many in English.

While English grammar is far more streamlined and less brittle than continental European languages (ie we have almost no case, no gender of nouns except for people, no agreement of adjectives and a word order that front- loads the verb in the sentence) native Asian language speakers still struggle with plurals, tense and the informal way we use tone (compared to the tonal languages).

The phenomes used in each language seem like the least important part.

Lastly, it's worth pointing out that there is as much variety in Asian languages as Indo-European languages. Arguably more since several language families span Asia.

<comment><USER15> > Asian languages are rather "grammar-less" (not that such a thing is > technically possible), at least compared to Indo-European languages.

Interesting you should say this, given that Mandarin (for example) has nearly the same grammar as English as far as word order and lack of a case system goes: Mandarin words, unlike words in French and German, aren't changed based on their role in the sentence, and Mandarin words don't have grammatical gender. English happens to be radically unlike most Indo-European languages in precisely the ways that make it fairly similar to Mandarin.

> While English grammar is far more streamlined

All languages have the same amount of grammar, distributed differently. (It's like a waterbed: Push the lump down _here_ and it springs up _there_.) English does more with word order and context than German, for example.

> The phenomes used in each language seem like the least important part.

Heh. Try saying that when you have to hear and reproduce a vowel sound that sounds like a warped tape, or a consonant that sounds like the speaker is rubbing gravel together in the back of his throat.

> Lastly, it's worth pointing out that there is as much variety in Asian > languages as Indo-European languages.

And in Africa. And in the Americas. And so on.

<comment><USER14> > English happens to be radically unlike most Indo-European languages in > precisely the ways that make it fairly similar to Mandarin.

I don't really view English as radically different. I just view it as more fluid. Mandarin I only know of peripherally. French I know some and German I know quite well. English really is very similar to German. Old English and Altdeutsch (Old German) were almost the same language (800-1200 years ago) but when French became the court language of England (after 1066), there was no central authority maintaining what common English was so it evolved into something very different with Middle English (which is almost recognizable as Modern English) by, say, the Tudor dynasty.

Linguistically speaking this was a very interesting phenomenon and one that I don't think has happened too often elsewhere (where the language of the aristocracy wasn't the language of the people and was essentially imported). It led to what I call the democratization of English.

I find it really interesting that the lack of a central authority imposing standards and maintaining the "purity" of the language actually led to it becoming much simpler.

> ... given that Mandarin (for example) has ...

Like I said, I'm no expert at Mandarin. A friend of mine has lived in Taiwan for years and learned Mandarin and he tells me a lot about it. One thing Mandarin has that English doesn't is formal tone (rising, rising-falling, etc). This can radically change the meaning. This is a mechanism for communication that native Mandarin speakers just can't find an analog to when they learn English.

> All languages have the same amount of grammar

While I think we'll both agree that certain languages are easier to learn for the speakers of certain languages than others (eg Spanish speakers learn Italian far easier than Mandarin, Mandarin speakers will learn Vietnamese far easier than Spanish) I disagree with your waterbed analogy, implying there's some sort of conservation of language complexity in play.

I believe that some languages are fundamentally easier to learn than others when you account for starting biases and also that certain languages convey information better and more easily than others.

Literacy is one measure of this. In 1929 (IIRC), Turkey's president switched their alphabet from Arabic to a highly phonetic Latin alphabet. Literacy rates shot up and someone who was previously illiterate could learn to read the new Turkish in ~6 months.

Compare that with Taiwan where they have competitions in _high school_ at how fast you can find words in the dictionary.

Also, as a speaker of English, if I'm talking to you on the phone, I can tell you a new word and how to spell it. There is no equivalent for Mandarin (with a new character).

My argument is there is a "cognitive price" to be paid for arbitrary complexity in a language as well as not front-weighting of information by importance.

An example of the latter: separable verbs in German. (jdm/etw) bringen = "to bring". (jdm) umbringen = "to kill" so:

Ich bringe meine Frau (I bring my wife) and: Ich habe meine Frau gebracht (I brought my wife) but:

Ich bringe meine Frau um (I kill my wife) and Ich habe meine Frau umgebracht (I killed my wife)

Likewise, the arbitrary rules about the agreement of number, gender, case and article (eg German can change depending on whether you're saying "a student" (indefinite article) vs "the student" (definite article) all other factors being equal).

</comment></comment></comment></comment><comment><USER16> I was disappointed the Philippines didn't make it on the list. I spent two years there and they are ridiculously obsessed with learning English. Add to that the 50 years they spent as an English colony and they, as a nation, are exceptionally good at English. Even slum dwellers I'd find were often fairly proficient.

<comment><USER17> The Philippines were in point of fact an American colony; I presume you meant English-speaking, as the English did their colonizing under the flag of Great Britain in any case and it is customary to refer to their colonies as British.

</comment></comment><comment><USER18> The full report describes their methodology as including (but not limited to) results from people who took an online test at ef.com - this is the test: <http://www.ef.com/master/tests/>

</comment><comment><USER19> As one would expect, the top of the list is dominated by small, peripheral European nations. As a Norwegian, I'm painfully aware that both my country and my language is too small to matter to anyone else. If I wish to interact with people abroad, I will have to do so on their terms, in their language.

And I do have to interact with people aboard. If you have a national economy or a cultural ecosystem consisting of fifty or hundred million people – like France, Germany or Japan – there's rarely a real _need_ to talk to anyone on the outside. There are enough newspapers, books, movies and records being produced in Japan to satisfy the domestic market – and the imported stuff can be translated and adapted without adding too much to the cost for each consumer.

For a country and language with less than five million people – not so much. We produced a total of 20 movies last year, and the climate on this frozen rock made sure our crops yielded only half of the food we actually need. If we didn't talk to anyone else, we'd be bored and starving.

Which regional great power dominates our trade and cultural input has varied over time. Norway was in the Hanseatic League's sphere of influence from the 1300s, and German language and culture had the greatest influence for almost a millennium. The harbour area of my home town of Bergen is still named "the German Wharf". And my great grandmother told the German soldiers approaching her in April 1940 to fuck off in perfect German.

During and after the war, the Anglo-american economic and cultural influence quickly surpassed the German. The Cold War brought us even closer to the US, despite the American culture being rather … incompatible with the Norwegian.

The stories are similar for most of the other small European countries. But how the English language influences the native tongue varies wildly from one country to the next. The differences are especially noticeable between Norway and Denmark.

Some more historical background first:

Norway is a very young nation-state. From 1380 to 1814, Norway was part of Denmark. From 1814 to 1905, Norway was in a personal union under the Swedish king. As of the 19th century, we didn't have our own written language. We spoke Norwegian, but wrote Danish. As Norwegian nationalism grew during the 1800s, a charming gentleman called Ivar Aasen set out to create a Norwegian written language. He traveled around the country, taking note of how people actually spoke. Dialects vary wildly between different parts of the realm (I haven't seen this much internal variation in any other country), but he did distill what he heard down to a set of grammar and vocabulary.

The adoption of Ivar Aasen's nynorsk (literally: New Norwegian), too, varied a lot from region to region. It was generally recieved well on the countryside. In the cities, the Norwegian upper classes had developed an amalgam dialect combining the original local tongue and Danish. They were greatly opposed to this uncivilized new language, and brought much of the urban working classes onto their team. So for the past 150 years, we've been been fighting, sometimes almost literally, about how to write. Today we have two official written languages – bokmål (literally: book language) and nynorsk. There was a stranded effort in the mid-1900s to unify them, but they have influenced each other a lot. Bokmål isn't very much like Danish anymore, and standard nynorsk is quite watered down.

The result of these struggles is that how a Norwegian speaks and writes is a significant part of his identity. The dialect shows which region you come from and which social class you belong to (or aspire to belong to), and each one comes with pride. Not chauvinism or jingoism, but genuine pride. I live in Oslo, but if I come home to Bergen and show signs of being influenced by the Oslo dialect, I will be ridiculed by friends and family. For real. (c:

Now, back to my point. The Danish language today is heavily influenced by English. The frequency of loan words is staggering. A number of English words have found their way into the Norwegian language too, but an order of magnitude less. I believe this is due to our history. The Danes were never colonized by anyone, and haven't spent much time philosophizing about how they speak or write. We have, and it shows.

(Other interesting tangents: Why have the Norwegian dialects diverged so much? Why can Norwegians understand Swedish but Swedes have a hard time understanding Norwegian? Why has Norway stayed out of the European Union? Why is the English influence of the Norwegian language more noticeable in the capital than elsewhere?)

<comment><USER20> Thank you. As someone somewhat curious about Norway (and Scandinavia in general; "it" being part of my heritage), your description provides some detail I'd not heard.

The regional dialects remind me of my time in Germany. There is considerable variation between the coastal areas and the Alps. I recall being freshly arrived in Munich and having a "genuine" (here in the U.S., if we were were joking or a bit mean, we might say "hillbilly") Bavarian as a neighbor. I couldn't understand a word he said (unless he made a conscious effort, and even then...). (He was a really nice guy, BTW, and we go along fine, despite this.)

I spent a lot of time with students in Munich, a city and university system that attracted them from all over. And there were plenty of light-hearted comments about others' accents and where they must be from. I think I was fortunate to be amongst a younger population for whom such things were more curiosity than a divisive issue. Older Germans... plenty of genuinely nice ones, but also sometimes some very entrenched feelings. Like anywhere, I guess.

I had a question for you, if you don't mind. Norway, Sweden, and Denmark seem to have so thoroughly integrated English as a second language. Where do you, and do people in general, seem to find the boundary between their native language and English in their daily interactions?

I've heard, for example, that if one attendee in a meeting is not a native speaker, the meeting switches to English and that really seems to be no problem at all. In Montreal, Canada, amongst the young technologists I visited, conversations would switch between French and English, and back again, in mid-sentence.

I don't have a compelling reason for asking; I'm just curious.

<comment><USER19> > Where do you, and do people in general, seem to find the boundary between > their native language and English in their daily interactions?

* If I speak to other Norwegians, I will speak Norwegian. Always. I make a conscious effort to keep the language free of any [recent] loan words.

* If I speak to Swedes or Danes, I will speak Norwegian. If I see they're having trouble following, I will speak slower and tone down my dialect. I will not switch to Swedish or to English. I understand them – they better do the effort of understanding me. (That's the 500 years as a colony kicking in. :)

* If I speak to a non-Scandinavian foreigner who doesn't understand or speak Norwegian, I instantly switch to English.

* If I speak to ten Scandinavians and one non-Scandinavian, I will instantly switch to English.

* If I speak to someone who has been in Norway long enough to understand the language but not long enough to be comfortable speaking it, I will speak Norwegian. I don't mind if he speaks English, but I'll stick to Norwegian if he actually understands it.

* If I speak to someone who doesn't really speak much Norwegian but tries hard to, I'll answer in Norwegian first – but usually switch to English when I see they're struggling.

All of the above apply within my own country. Abroad, I will try to speak the local language if I can. If not, I will ask, in the local language, if they speak English and then switch. If I'm spoken to in English, I will respond in English.

<comment><USER21> >If I speak to someone who doesn't really speak much Norwegian but tries hard to, I'll answer in Norwegian first – but usually switch to English when I see they're struggling.

I'm Norwegian, and had a neighbor from England. He said that it is hard to learn Norwegian because we tend to switch to English when talking to him. We often started the conversations in Norwegian, but (too) quickly moved to English.

<comment><USER22> In my experience as a foreigner in Scandinavia, Swedes are way way faster to switch to English, many do it almost as soon as I make a small mistake, whereas Norwegians are much more tolerant and will keep up unless I switch myself.

</comment></comment></comment></comment></comment><comment><USER23> Jean-Louis Borloo, who at some point in time was rumored to be the next Prime Minister of France, just launched (today) a new political formation, called "Alliance Républicaine, Sociale et Ecologique".

It doesn't really mean anything, but it spells: ARSE.

It's going to be fun when he shows his business card to British journalists...?

If you don't believe it (I couldn't), see:

[http://www.lecentrisme.com/2011/04/actualites-du-centre- jean...](http://www.lecentrisme.com/2011/04/actualites-du-centre-jean-louis- borloo.html)

<comment><USER24> "Okay, Lindsay, are you forgetting that I was a professional twice over - <USER2> analyst and a therapist. The world's first analrapist."

</comment></comment><comment><USER25> Very interesting. Evaluating the English skills based on tests is like evaluating programmers based on how well they do on programming contests (i.e ICPC). For example, if this test was given to high school students about to graduate, I would expect China to be in top.

</comment><comment><USER9> "This was not a statistically controlled study: the subjects took a free test online and of their own accord."

This is by far the most important point made in the article in The Economist, but so far it is little reflected in the comments here on HN. The reported results have some broad plausibility to me, as a native speaker of General American English who has lived overseas (including living in an international dormitory with residents from all over the world, who variously used English- as-a-second-language, French-as-a-first-or-second language, Spanish-as-a- first-language, or Chinese-as-a-second-language as interlanguages). But the reported results may or may not reflect the reality of the situation in the real world, as the editor of The Economist takes care to note.

It's time to dust of the electrons on my FAQ post on voluntary response polls.

VOLUNTARY RESPONSE POLLS

As I commented previously when we had a poll on the ages of HNers, the data can't be relied on to make such an inference (what the average age of HN participants is). That's because the data are not from a random sample of the relevant population. One professor of statistics, who is a co-author of a highly regarded AP statistics textbook, has tried to popularize the phrase that "voluntary response data are worthless" to go along with the phrase "correlation does not imply causation." Other statistics teachers are gradually picking up this phrase.

\-----Original Message----- From: Paul Velleman [firstname.lastname@example.com] Sent: Wednesday, January 14, 1998 5:10 PM To: email@example.com; Kim Robinson Cc: email@example.com Subject: Re: qualtiative study

Sorry Kim, but it just aint so. Voluntary response data are worthless. One excellent example is the books by Shere Hite. She collected many responses from biased lists with voluntary response and drew conclusions that are roundly contradicted by all responsible studies. She claimed to be doing only qualitative work, but what she got was just plain garbage. Another famous example is the Literary Digest "poll". All you learn from voluntary response is what is said by those who choose to respond. Unless the respondents are a substantially large fraction of the population, they are very likely to be a biased -- possibly a very biased -- subset. Anecdotes tell you nothing at all about the state of the world. They can't be "used only as a description" because they describe nothing but themselves.

[http://mathforum.org/kb/thread.jspa?threadID=194473&tsta...](http://mathforum.org/kb/thread.jspa?threadID=194473&tstart=36420)

For more on the distinction between statistics and mathematics, see

<http://statland.org/MAAFIXED.PDF>

and

<http://escholarship.org/uc/item/6hb3k0nz>

I think Professor Velleman promotes "Voluntary response data are worthless" as a slogan for the same reason an earlier generation of statisticians taught their students the slogan "correlation does not imply causation." That's because common human cognitive errors run strongly in one direction on each issue, so the slogan has take the cognitive error head-on. Of course, a distinct pattern in voluntary responses tells us SOMETHING (maybe about what kind of people come forward to respond), just as a correlation tells us SOMETHING (maybe about a lurking variable correlated with both things we observe), but it doesn't tell us enough to warrant a firm conclusion about facts of the world. The Literary Digest poll intended to predict the election results in the United States in 1932

<http://historymatters.gmu.edu/d/5168/>

<http://www.math.uah.edu/stat/data/LiteraryDigest.pdf>

is a spectacular historical example of a voluntary response poll with a HUGE sample size and high response rate that didn't give a correct picture of reality at all.

When I have brought up this issue before, some other HNers have replied that there are some statistical tools for correcting for response-bias effects, IF one can obtain a simple random sample of the population of interest and evaluate what kinds of people respond. But we can't do that in the case being discussed here in this thread on HN.

Another reply I frequently see when I bring up this issue is that the public relies on voluntary response data all the time to make conclusions about reality. To that I refer careful readers to what Professor Velleman is quoted as saying above (the general public often believes statements that are baloney) and to what Google's director of research, Peter Norvig, says about research conducted with better data,

<http://norvig.com/experiment-design.html>

that even good data (and Norvig would not generally characterize voluntary response data as good data) can lead to wrong conclusions if there isn't careful thinking behind a study design. Again, human beings have strong predilections to believe certain kinds of wrong data and wrong conclusions. We are not neutral evaluators of data and conclusions, but have predispositions (cognitive illusions) that lead to making mistakes without careful training and thought.

Another frequently seen reply is that sometimes a "convenience sample" (this is a common term among statisticians for a sample that can't be counted on to be a random sample) of a population offers just that, convenience, and should not be rejected on that basis alone. But the most thoughtful version of that frequent reply I recently saw did correctly point out that if we know from the get-go that the sample was not done statistically correctly, then even if we are confident (enough) that Norwegians who responded to an online poll are reasonably fluent in English, we wouldn't want to extrapolate from that to conclude that any particular social or educational factor present in Norway provides an advantage in learning the English language, or that Panamanians on average are some of the least fluent speakers of English in the world.

On my part, I wildly guess that most western Europeans who have completed secondary education in the last three decades are moderately fluent in English, if only because they have occasion to use English as an interlanguage when speaking to other Europeans (something I have seen happen many, many times) and because they have much exposure to English-language media content (books, movies, radio broadcasts, TV shows). People who live in Latin America and who have occasion to travel to neighboring countries (including Brazil) have considerably more occasions to use Spanish as an interlanguage, even with native speakers of Portuguese, and thus somewhat reduced tendency to keep their English in practice.

The way to know which social or educational or economic factor is most important in the spread of world English as the global interlanguage would be to do an even more careful study than the interesting preliminary study reported here. Meanwhile, we will be trading anecdotes based on personal experience, which I will read with interest to supplement my personal experience.

</comment><comment><USER26> Empirical Forum... English = Technology = World Domination..

</comment><comment><USER27> I can guess why the Dutch are better english speakers than we here in Germany. In the Netherlands movies and tv-shows are not dubbed - only subtitled. In Germany everything is dubbed.

Since I decided to watch movies and shows in english my (actively spoken) english improved (reading and understanding was never a problem). It's not perfect but it's far better than the english I was speaking after I left school.

Blame the TV :)

<comment><USER28> Yep, same reason strongly applies to Italy too. (also Italian dubbers are among the best in the world, Italian versions of popular US shows won prizes for the best dubbed edition, so from time to time I even happen to see original versions thinking I enjoyed more the Italian one).

I tried to put my son in front of a TV with just English things, but it is hard for a 10 years old to accept to understand just one word from time to time in a moment that should be about relax (cartoons time).

<comment><USER29> No kidding: As a result of the quality of Italian dubbers, Italians do not see anything unusual in Keanu Reeves acting skills. I brought this up in conversation multiple times a few weeks ago in Italy near Bologna. They think he can act.</comment></comment></comment>


Tell HN: GoDaddy apparently loves our startup's pricing structure - <AUTHOR>

GoDaddy recently updated their homepage which includes a portion which is eerily similar to our own pricing structure on POP.co. We're fairly new on the block and loosely compete against the bigger registrars with a different take on how you should get your ideas online. It's David v. Goliath over here, but we're flattered they think so highly of our work!
I'll follow up in the comments with a link to the screenshot and our site.
What are everyone's thoughts here on HN? <comment><USER2> A very quick look at Archive.org suggests godaddy rolls out new homepages _really often_ and they all look pretty contemporary, so it's probably a coincidence that something in their queue also looked like your site.

You could probably learn a lot by monitoring their designs btw and seeing how long they use them and what elements are persisting (aka working) across designs.

</comment><comment><AUTHOR> Here's the screenshot and our company url:

[http://imgur.com/i5p7XTC](http://imgur.com/i5p7XTC)

[https://pop.co](https://pop.co)

</comment><comment><USER3> This is a pretty generic way of showing your pricing, I wouldn't look into it too much..

</comment><comment><USER4> What!? I looked at the two screenshots and the two look nothing like each other?</comment>


A very simple Go non-ORM - <AUTHOR> https://github.com/jaekwon/go-modeldb

<comment><AUTHOR> I created it while developing for a personal project. I found it useful so I thought I'd share it.</comment>


Procrastinators Rule Among Wishful Entrepreneurs - <AUTHOR> http://www.caycon.com/blog/2011/08/procrastinators-rule-among-wishful-entrepreneurs/ <comment><USER2> I don't doubt any of it. Makes me extra sad because I have an idea, I'm working on the new development skills I need to execute it, I have a business plan... but visa restrictions mean that I'm not able to set up my own company. Extremely frustrating.</comment>