Ask HN: What would you do with 6 months of free time? - <AUTHOR>

I'm graduating from college this month, and just accepted a job that I'll start in June-July. I was lucky enough to get a signing bonus as well as have some money saved up, and I want to put this gap time to good use.
I've got a few side projects that I've been putting off that I could work on, and a few hobbies that I could spend some time on (photography, for one), but I could do these things anytime.
Any particular places to travel? Any experiences that I could go and seek out in this time? Any other ideas? <comment><USER2> I've always loved traveling to places where the standard of living is much cheaper then where I live. This way you can eat better and do way more extravagant things while potentially _saving_ money. Between 5 star meals you could be hacking your side projects from a posh roof top patio and when your in a slump you can go site seeing.

The other advice I'd give to traveling to relatively exotic places is to somewhere that someone you trust knows well; preferably with said person. The best way to find all the gems of a new place and get a real feel for the local flavor is with someone who knows how to showcase it. If you have friends from interesting places see if they can help you plan a trip, or see if they can join you for some portion of the excursion.

</comment><comment><USER3> I'll be in the same situation in 2 months, leaving my current job in a social network company. I'm going to spend some time on my own projects, and start freelancing while traveling in South East Asia.

When you'll have your day job, you'll have very little time to work on your side projects, so I would say take advantage of that now. That, or traveling for an extended period of time is also very eye-opening if you haven't done it yet. South America is still my favorite place. In 6 months you can see most of the continent, not sure if you'll want to go back home though :-)

<comment><AUTHOR> South America is tempting, my only concern is that I have no knowledge of spanish (I took 6 years of french and am a proficient reader).

<comment><USER4> Not necessarily a problem... <http://www.fluentin3months.com/>

</comment></comment></comment><comment><USER5> I will travel, or be a volunteer or both things at the same time.

After I drop the college, I went to north Italy, bought abandoned house and I restored it. I learned a lot of stuff.

If you are from US, maybe go to Europe is quite expensive at this moment, and probably you can get more in south america for your bucks.

If you have an idea about what kind of experience are you looking for, maybe we can give better advices.

</comment><comment><USER6> I'm in a similar situation. Ideally in 6 months, i'd like to be proficient at Rails, familiar with Haskell, and build an income source stable enough to not have to get a job. (ie.. be ramen profitable) So that's where my 6 months are going

</comment><comment><USER7> Set a deadline (maybe 6 weeks) and finish a side-project I have going on - While still in 'work mode'. It frustrates me sitting around at my day job and then scrambling to work on it in free time/travel time.

I'd love to get up, get ready in the morning, (go somewhere, ideally) and do 8 hours of MY work a day.

</comment><comment><USER8> I'd go to Central America, study my brains out, and learn Spanish. Knowing another language is invaluable. It's very doable to become very proficient (not fluent though)in another language during this time - I've done it. Antigua, Guatemala has some of the best and cheapest one on one tutoring in the world.

</comment><comment><USER9> Go somewhere you have never been, and eat something that makes you grossed out.

<comment><AUTHOR> That might be hard to do without getting into some very gross things, but I definitely appreciate the sentiment.

</comment></comment><comment><USER10> Take a month or two and do nothing.

</comment><comment><USER11> Just out of curiosity, where will you be working?

</comment><comment><USER12> I ask myself the same question every year.</comment>


How Does IQ Relate to Personality? (2014) - <AUTHOR> http://blogs.scientificamerican.com/beautiful-minds/how-does-iq-relate-to-personality/ <comment><USER2> 2014\. (Discussed here before, I think.) The article kindly submitted here does not represent a majority view among researchers, by the way. Another article you can see for free online (a book chapter by an author whose chapter was part of a book edited by the author of the submission here) presents what I observe to be the more mainstream view.

[http://www.tc.umn.edu/~cdeyoung/Pubs/DeYoung_Intelligence- Pe...](http://www.tc.umn.edu/~cdeyoung/Pubs/DeYoung_Intelligence- Personality_Chapter.pdf)</comment>


Ask HN: Is there some unwritten code of conduct for code reviews? - <AUTHOR> Code reviews are all the rage these days: I am getting code reviews at work from people whom I don't even know; Is there some accepted code of conduct for this kind of situations?
I mean is one supposed to just do what any reviewer is suggesting, or is there an acceptable way to resolve differences of opinion? <comment><USER3> Google's engineering practice documentation has a section on 'The Standard of Code Review': [https://google.github.io/eng- practices/review/reviewer/stand...](https://google.github.io/eng- practices/review/reviewer/standard.html)

It includes this important rule:

> In general, reviewers should favor approving a CL [changelist - <USER2> > to a patch] once it is in a state where it definitely improves the overall > code health of the system being worked on, even if the CL isn't perfect.

<comment><USER4> I'm really glad this was posted. The rule that makes sense to me, when before I didn't know where to draw the line between accept and nitpick. Gonna start thinking about this in code reviews going forward.

</comment></comment><comment><USER5> In theory a code review should be a conversation in which you reach consensus.

The goal should be that the reviewer understands the code and what it does and is satisfied with the other things.

In reality what often happens is a busy programmer looks at it, spots that there is a { in the wrong place, flags that and considers his/her job done and moves on.

If someone flags something in a way that you disagree/or don't understand the best approach is "Can you explain why you think your approach is better than mine and what the trade-offs are?" in which case you'll either get an answer that is satisfactory and accept their changes or not in which case you then have to escalate it again.

If you think of it as asynchronous pair programming rather than a chance for someone to nitpick everything you do then it's more obvious how to respond.

<comment><AUTHOR> At what stage of the argument is one going to be flagged as uncooperative?

<comment><USER5> At whatever point one party pisses off another in some way.

You can delay that point by been open and reasonable up to a point, if you can't then reach consensus you need to escalate it to a lead/PM.

It can get both messy and personal if you aren't careful because two programmers might often solve a problem equally well but differently and therefore there simply isn't a clear correct answer.

In those cases I'd tend to default to the solution of the person who wrote the code (simply because they'll have put more thought into each part than the person doing the review usually).

Team dynamics will largely play a part as well, you may have an incredibly good programmer who can't take criticism at all well (seen that) or whatever and then it becomes a management problem rather than a technical problem.

A lot of it is simply tone and empathy though, "I'm curious why you did A instead of B here?" against "Why the hell didn't you do B?" or "B is clearly superior!" (with no explanation of why or the trade-offs).

Asking clarifying questions is often a good way to drill down to the meat of the problem (and in a good code review environment imo one of the strongest benefits, it increases comprehension of the code and intent for all parties).

One of my lecturers used to say "there are no technical solutions to a people problem".

<comment><AUTHOR> Thanks! So one possible answer is: try to reach the other party directly as soon as possibles (directly so that the discussion is not logged as responses to the code review log), this might help to reach consensus without stepping on anyones toes, so to speak. (and before the other party feels like it wants to escalate the issue) I think it is better to keep the discussions like this off the record, because the other party might not feel confident to formulate his/her position in a formal manner or might feel insecure about having this kind of paper trail .

</comment></comment></comment></comment><comment><USER6> There isn't one standard answer. The overall idea is to get another set of eyes on any code before it hits production, to help catch places where it could be improve, catch bugs early, help each other find better ways of doing things, etc.

In practice, some teams do this very well and it an ongoing discussion of good practices that makes everyone better. Other teams nitpick over trivia, asking everyone else to code it like they would have. Some teams require an actual approval, others just toss all the code up for a while before merging it whether or not it got reviewed. Sometimes a lead reviews it all and say yea/nay, other times it is a teaching tool to expose people to new areas of the code before asking them to help out in that area.

In other words, no - there is no standard code of conduct across the industry. But there should be some common understanding of how your team, specifically, is doing reviews, and what expectations exist.

</comment><comment><USER7> Code review, IMO, is specific to an org and how it wants the culture and codebase to mature overtime.

Careless, quick reviews are going to foster an environment where PR authors do not feel adequately supported where as pedantic, nit-picking reviews are going to exhaust.

As for the semantics, it's often about being idiomatic in the language and adhering to good design, i.e. if some requirement changes -- can this change with it?</comment>