specialk

There is a supply and demand tension in Dublin over accommodation. Building more apartments, i.e. increasing supply, will help alleviate this tension. That doesn't mean we can't also tackle the problem from the other direction by reducing demand. AirBnB is demand.

It's hard to tell how much any government would want to pull on a lever that might reduce demand. Those tourists bring valuable outside revenue into the city. We need them too. There's lots to balance here. Let's not optimise just revenue.

Wearing headphones

Working away from normal desk

Interruptions still happen, of course. When one does, we suggest letting the person know upfront that you’re concentrating on something, and asking them if it’s urgent. And if you’re the person doing the interrupting, try not to get offended when you get asked if your needs are urgent.

OMG yes big fan of this. Setting expectations up front for this kind of behaviour is great. Without a 'culture' for allowing people to stay focused without an immediate interruption, I have always found it hard to explain to people interrupting me why they could have used an asynchronous communication tool, like Slack/HipChat/email, for non-urgent questions.

So, if you'll indulge me, your argument is essentially 'us vs them' is a bad thing. About right? If so, I agree. We're not going to solve an exclusionary tech culture by excluding people or creating two sides to a debating war.

But what strikes me is that your comment didn't even reference Nicole Sanchez by name once. Your comment was "she" and "her" time and time again. Did you even notice yourself do it? I somehow doubt it was intentional. But I'm an optimist.

If the pull request is small, fixes a bug or is a blocking you, then you can spend you quick-code-review-chip for the week and ask the team to look at it at their first available opportunity. (Sometimes reviewed within 15 minutes, usually an hour tops)

It allows team members to ask the rest of the team to unblock them quickly. Limiting it to one a week prevents abuse of their team mates' time and encourages all team members to plan their work out ahead as to reduce blocking.

We also wrote a quick HipChat bot that keeps track of who's spent their quick-review-chip too.

In work I currently have 3 pull requests open all touching different sections of the product. The 3 PRs are all at different stages of the review process. For example, I'll be closing one first thing tomorrow and deploying it out (don't like deploying in the evenings - its bad luck). Another I just opened as I left work today, so I doubt anyone's reviewed it yet.

I'm sure Quora has a big enough codebase and not enough developers (like most companies) that they always have a list of things a mile long that they would like to do or should do, be that new features or just refactoring.

2-3 days isn't long for a review and iteration cycle in itself. I have one PR that is currently open for 5 working days at this stage. We decided that it didn't quite fit the bill on the first draft . It is blocking progress on two other tasks in our backlog but we also have 14 things on our backlog of goals for this week. The team is working around it while we finish it off or create issues for things we think have fallen outside the scope of the initial job.

One thing we've noticed alot on my team is that we try and make our pull requests for review as small as possible. We all have a rough guide of about max 500 lines. Sometimes we do go over but its a rough guideline. Smaller PRs are just easier to review for everyone involved. Reviewers don't have walls of code to break through or need to keep tons of context in their head.

Post-commit reviews (or post-merge into master or whatever you process is) is an interesting idea. I'd be curious to see what my team think of the idea tomorrow for a small sub set of our codebase.