VIP News

This blog is aimed at helping publishers and brands get the most out of WordPress. We cover features that are often overlooked, highlight plugins that extend WordPress functionality, and showcase interesting sites being built with WordPress.

Helpful Technology is a relatively small London consultancy specialising in digital engagement. One area of focus for Steph Gray’s team is corporate intranet development; and they have had great success deploying a WordPress-based intranet solution inside several UK central government departments.

Steph and his colleague Luke Oatham joined us at March 2015’s London Big Media & Enterprise Meetup to talk about the features which had made the project a success. And if you like what you see, their code is available as open source for anyone to use and improve.

Duncan Stuart is Head of Products at dxw, a London agency specialising in projects for the public sector. He has a particular interest in security; and at our London Big Media & Enterprise Meetup in March 2015, in a presentation entitled ‘Snakes In A Plugin’, he demonstrated the most common vulnerability they find when conducting security reviews of WordPress plugins.

The white paper is an analysis and explanation of the WordPress core software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating WordPress as a content management system or web application framework should use the white paper in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.

We’d really love to encourage and help share translations of the white paper to the global WordPress community. If you have a translation to contribute, please add it to the WordPress GitHub repo so others can benefit, too. Pull requests welcome!

The text in the white paper (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.

Thank you to all who contributed to the initial release and compilation of this document: Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, and Paul Maiorana.

Below is the table of contents for the white paper, which you can find here.

A special note: As you can see in the table of contents, the white paper is specific to the open source core WordPress software. The core WordPress software is the foundation of WordPress.com and there are additional Security FAQ related to WordPress.com VIP here.

We hope you’re staying out of the snowdrifts and keeping warm wherever you are, and we wanted to make sure you knew of some upcoming events the WordPress.com VIP is organizing or participating in, in the near future. We hope to see you and have a chat at any of these events!

We’re meeting & greeting in Seattle! If you’re in or around the Seattle later this month, several members of the WordPress.com VIP team are hosting an informal meet and greet on February 24th! Please get in touch if you’ll be in the area so we can send you an invite.

The Big Media & Enterprise (BM&E) WordPress Meetups are a great way to meet other developers, product managers, and editorial teams who use large, high-traffic WordPress sites. The evening is usually centered around 3-4 flash talks followed by discussion and networking. Past BM&E events have been held in NYC, Boston, San Francisco, Toronto, and London.

March Big Media & Enterprise Meetup

Tuesday, Mar 10, 2015, 6:45 PM

Workbar Cambridge45 Prospect Street Cambridge, MA

45 Members Attending

** Update Part 3: We’ve rescheduled this meetup to March 10 because of snow and transit difficulties. Thank you for your patience! **The Big Media & Enterprise meetup is open to developers, product managers, and editorial teams who run large, high-traffic WordPress sites. If you plan on attending, please be sure to RSVP.Doors open at 6:45 p.m.,…

March 2015 Meetup

Tuesday, Mar 10, 2015, 6:30 PM

Westminster HUB 80 Haymarket #1st floor SW1Y 4TE London, GB

15 Members Attending

The Big Media & Enterprise meetup is open to developers, product managers, and editorial teams who use large, high-traffic WordPress sites. If you plan on attending, please be sure to RSVP as space is limited.Doors open at 6:30 p.m., presentations will begin at 7 p.m. We will have 4 “flash talk” presentations, each lasting 10 minutes, followed by…

April 2015 Big Media & Enterprise WordPress Meetup

Wednesday, Apr 8, 2015, 6:45 PM

Automattic Lounge132 Hawthorne St San Francisco, CA

1 Members Attending

The Big Media & Enterprise meetup is open to developers, product managers, and editorial teams who run large, high-traffic WordPress sites. If you plan on attending, please be sure to RSVP as space is limited.Doors open at 6:45 p.m., presentations will begin at 7 p.m. We will have 4 “flash talk” presentations, each lasting 10 minutes, followed by …

Gabriel Koen from PMC (Variety.com, Deadline Hollywood) presented “Launches: Lessons Learned” at the recent Big Media & Enterprise Meetup in San Francisco, California, now available with full transcript.

View the presentation slides below:

I come here from Penske Media I’m going to be talking essentially about our product launches and what’s gone wrong and how we’ve used that to essentially adapt what we do and how we do it.

For those of you who haven’t heard of Penske Media, you might have heard of some of our brands. This includes TV|Line, Deadline, Variety, BGR, entv, Hollywood Life. We run about 30 events, including some that are on, I don’t even remember what, CW I think, and a couple of others.

To give you an idea of what our launch schedules tend to look like over the last few months, everything from new major sections on our sites to actual site redesigns and brand new sites themselves.

We launched mundial section for Variety Latino, a Contenders Awards aggregation section for Variety. Back in May we did a full on site redesign launch for TVLine events, like our power of women event, International Editions on Variety, a new section for our events. And generally, every month we do at least six or so brand new products or sections for our sites. Anything from just a new page, to a new major feature, to brand new site.

So basically getting on to what we’ve done, these are in no particular order. So one of the things that’s the most common that we’ve run into in the past especially is you know, we go through all this trouble launching a new feature, a new section on the site and 3 months down the road we realize hey we’re not getting any mobile traffic to this section.

So obviously, we forget to add a link to it, to our mobile themes header or side bar or you know even forget a mobile optimized version of it.

Sometimes the solution is changing the way that you develop or think about your products in general.

It’s odd but it happens and then essentially we’ve targeted that by we’re making a push to do a responsive theme for all of our sites at this point and I think the number one driving reason for that, aside from higher mobile engagement as the years go on is just that, you have to account for different devices and different sizes when you’re dealing with responsive. You know, it gets bakes into your QA processes and your thought patterns.

So the key take away from that is just not every problem that you encounter has a solution like “oh yeah I need to remember that”, sometimes the solution is changing the way that you develop or think about your products in general. More so than “ oh, I have to remember to do this on launch day”.

Another big one, especially a big problem for sites like ours that are ad-driven for our revenue, we forget to loop in different team members or different people within the organization and then we find out they were completely unaware of the launch and you know, we didn’t think that they needed to know.

So you know something happens like ads don’t even show up on your new section, or the wrong ads show up in the wrong places on your shiny new website design. So in order to combat that we started doing cheat sheets where prior to each launch, we just put together a simple one-sheeter that explains okay, here’s all the key dates, people involved and milestones that are going to get us from the concept to actual page on site.

So the overall take away there is just every team involved knows who else is involved and what other teams are there someone in there is bound to know “hey so and so from the editorial team or from our vince coverage team is gonna need to be involved in this and it just helps circulate the communication there.

We just put together a simple one-sheeter that explains here’s all the key dates, people involved and milestones that are going to get us from the concept to actual page on site.

We have had launches where we forgot to actually turn it on whether it’s actually activating the theme or enabling a core feature for the theme or dragging the widget to the sidebar.

And the problem there is there wasn’t one person who was owning that launch or that feature, that particular thing. So from then on, we just have to make sure that every thing that’s on our checklist, everything that’s happening, has one person that owns it, since we found that everyone on the team may know what’s going on but they may think that someone else is actually going to do it.

And sort of adjunct to that is you know, it’s useful, we’ve found that, you need to have someone who’s, with a small team especially, you tend to get focused on all the little pieces needed to pull the whole thing together, but the way things like this get missed is you tend to not have somebody just keeping the eye on the overall thing or project or launch and just making sure all the piece fit together.

And we’ve had launches where the key stakeholders never actually saw the feature we were building before we built it and pushed it out. So obviously hilarity ensued once actually saw that we launched a major section of the site that they were responsible for or feature that they had to suddenly start populating content for etcetera.

So essentially to combat that, we realized in addition to just making sure that we flip the switch and loop in ad ops teams and editorial teams and what not, we need to make sure that communication was actually part of our list. You know, so at a certain point, it’s like one of the steps is make sure that you know who to communicate this to make sure that you actually get them to review it at certain points.

From then on, we just have to make sure that every thing that’s on our checklist, everything that’s happening, has one person that owns it

So you know, treating your milestones and key communication points as actually just something else you do just like QAing the feature, just like building it, just you know, every other piece of it.

And one of the last two are kind of some of the more embarrassing ones at least from my point of view. So the times when we broke something and just kind of hoped that nobody would notice while we were scrambling to fix it.

And of course, meanwhile, the actual stakeholder sees it and you know, starts being very vocal about seeing it, which very quickly escalates the situation. So it’s kind of obvious in hindsight, but you just have to you know, own up to what you’re doing. Whether it’s good or bad, when things are going wrong, when things are running late, you just have to make sure that you’re, you know, keeping constant communication going with your key stakeholders for a project.

Key stakeholders, just a sidebar for a second, could be anyone from if you’re launching a new section, well it’s going to the the editor or writer of that section it could be the general manager of the site. Just whoever it is that is most invested in the success of that project or product.

Whether it’s good or bad, when things are going wrong, when things are running late, you just have to make sure that you’re, you know, keeping constant communication going with your key stakeholders for a project

And then I think the key thing that we also learned from it is overall, those, it stings a lot less whenever you go to someone and say “hey we just noticed we did this or something happened, we’re actively working on it and we wanted to let you know and keep you in the loop” than them suddenly looking at their site and seeing a mess, you know.

Other ones are right after our launches. Having the general manager of the site say, “hey I noticed I’m getting fewer page views can you look into it?”

What’s going on? Well many things. We found a couple times where we’ve accidentally blocked search engines from indexing things we had meta tags or robot […] files from our dev sites that made it into production and we just never looked because who would do that?

Other times, we left analytics off of pages, especially when doing ajax operations and you know, things that aren’t a strict load where you still want to track page views or other engagement based off of that.

So essentially what we’ve found there is kind of a two-fold answer because there’s multiple problems there. First, it is not making assumptions. Maybe you looked at something or scanned it at one point and said “oh yeah, that looks good” and you move on.

Or maybe you’re just like, “yeah of course we’re tracking page views on this why wouldn’t we do that?” And the kind of take away that we really got driven home in those scenarios is, product launches do extend past the launch date.

Not only from just keeping an eye on things and just making sure things are working, but just from this point of view of from if you’re a product person, measuring the success of the product or project that you’ve just pushed out.

Is it working? Are people actually using it? And being able to respond to those things that you see, whether it’s in analytics or whatever so, that’s pretty much it.

Just to quickly go over how we at PMC have overall handled dealing with these things we’ve sort of, we start with the idea of let’s just do something and let’s just do it as a small team and see what works and what doesn’t work.

As we make mistakes, we introduce process to combat those mistakes that happen frequently and we constantly strive to reevaluate whether what we’re actually doing is working or not.

So we know that as we grow in size and as our sites grow in complexity, there’s just more process that you have to do to be able to handle these various scenarios. But we also know that process can kind of get in the way and the more process you have, the less likely you are to actually follow those processes, so it’s really finding a very happy balance between the two so that you’re actually being effective with the things that you’re trying to do.

So I’ll just kind of go over these quickly you know, it starts with project planning we typically work backwards and forwards from our launch date to make sure that our timelines meet somewhere in the middle, to make sure that we’re identifying all the people who are involved in the project and getting them looped into the timeline discussions.

We put together our little one-sheeter cheat-sheet with stakeholders, dates, URLs for being able to test things and check things dates, when they can go in and look at it, that type of thing.

We have one checklist for what we need to do before we launch, things like who we need to coordinate with to get on the actual launch time, it’s usually the WordPress.com VIP folks and then we need kind of configurations that we have to deal with.

We have our timeline for launch day, it’s literally a minute by minute calendar with who’s responsible for something and what the status of it is. We use Google Docs for all of this because our company is on Google Apps for business, but previously we used things like Trello and whatever works.

The key to all of this is to make it easy for people to access. Since we’re on Google Apps and using Google spreadsheets, we don’t have to do anything special for someone to log in and see a sheet or someone to edit it or for someone to have access to it.

Then we have our actual launch checklist, just a general overview of what needs to be done and who owns that piece of testing or review and we go through that once right before we launch and once right after we launch.

One of the newer things that we’ve introduced that’s been really successful is our support structure. Essentially we’ve started creating a chatroom, sometimes it’s a Google hangout sometimes it’s a Skype chatroom, it depends on who the stakeholders are and what they use every day.

On launch day, we everybody gets into the chat room, and that way whenever somebody comes across a problem or something, they just type it in or say what they’re seeing and you have that instant one-on-one communication.

We also try and identify one or two key people on the team, like if you’re doing a site launch, it might be the general manager of the site and the lead editor.

They’re the conduit between the writers and the other staff on the site and us so it lessens the noise that goes on on those launch days and our ability to find out what is actually a problem.

So that is basically it. Any questions?

Q: One thing on the VIP team that we’re really bad at right now is celebrating our launches internally So when we put in weeks or even months working towards a launch, we’re not very good at patting on the back and saying nice job, good effort, all that stuff.

Do you guys do anything like that to celebrate the launch or sort of like, boost internal moral?

A: That’s actually a very good point, that should actually be part of this because it’s certainly something that all of us on the team have strived to make part of our launch process. You know, we’ll send out an email and we’ll include the CEO and other people on it just saying “hey, this went live”, if there were people who were really, you know, worked 24/7 to get it out, we’ll make sure they’re acknowledged in that.

Our CEO is actually really great about it as well, he’ll respond and say fantastic job, especially, Amit Sannad or whoever else on the dev team that has been working weeks and weeks to get the thing out.

You know, we’ll usually, it’s tough because we have a distributed team as well, so those of us, like most of the product team is based out of Los Angeles, so we’ll get together and go out and have drinks or something like that.

We just try and, we’re still working on figuring out how to better include the people who are located outside of our office area. So far, we’ve just been making up with small gifts and tokens of appreciation thanks and emails and pats on the back and so forth, but we ‘re trying to find ways to do better on that.

Q: Do you use automated testing at all to help eliminate some of those issues?

A: We don’t. Sorry, he was asking if we use any sort of automation or automated testing to help with these things, and you know the short of it is we don’t. There’s a lot of reasons why we don’t and none of them are really that good.

Most of them boil down to like we haven’t found out how to automatically test for some things. We have introduced some types of automated tests like we have pingdom alerts that look for the ad strings on our various pages so we know if ads aren’t rendering and things like that.

But we’re still not at the point where we’re using any kind of unit testing. We’re not using any kind of selenium or UI testing. It would definitely help quite a bit with some of these things.

Applications are now open for the WordPress.com VIP internships! We’re currently focused on applications for the summer 2015 period, but we’ve also opened up a dedicated internship application form which will allow interested students to apply for internships on a rolling basis during the year.

Our company Automattic — which runs WordPress.com, Akismet, VaultPress, and many other services — is looking for a few stellar student interns, specifically to work with us on the WordPress.com VIP team. WordPress.com VIP provides hosting and support for high-profile, high-traffic WordPress sites, including Time.com, FiveThirtyEight.com, qz.com, TechCrunch.com, Recode.net, NYPost.com, etc.

Where will you be working you may ask? Anywhere! We are a distributed company and are happy if you work from wherever you are — as long as you have a good broadband connection.

2014 has been a big year at WordPress.com VIP. So far, we’ve served more than 28 billion pageviews (or, 28,250,403,658 the last time we checked). We’ve also added 350 new sites to the VIP network and 13 new members to our team (including an acquisition)!

As the leading WordPress solution for enterprises, we pride ourselves on working with your team to ensure that your code is optimized, secure, and fast. This year our customers have deployed changes 31,000 times, comprising more than one million lines of code—and we’ve reviewed every line. (And in case you were wondering, 4pm ET on Thursdays is the busiest hour in our deploy queue).

July

We introduced in-dashboard live chat support for the 22,000 editors, authors, and contributors across the VIP network. Our team is on stand-by to assist users and help them get their work done more efficiently.

August

Robin Williams’ death was covered by almost every news site in the VIP network, with more than 221 million pageviews over a span of roughly 48 hours.

September

We welcomed Fusion.net, a joint venture between Disney/ABC and Univision, onto WordPress.com VIP.

October

We geared up for another set of our VIP Training Days events around the United States – these 1-day courses bring VIP training to a city near you, whether it’s the Superuser, Developer Fundamentals I, or Developer Fundamentals Site Security & Debugging courses you’re interested in.

November

Another huge traffic day for the VIP network this year were the 2014 midterm elections. As the results unfolded we followed along the live blog on FiveThirtyEight.com. (Read more on how politicians and government groups are using WordPress to power their sites here.)

So to get a sense of what the room looks like, how many people here are developers? So the majority of people, probably 70-80 per cent. How many people are editorial? A few people, that’s good. How many people are management? You guys in the suits.

If you’re a developer, how many people have a code review process built into their teams right now? Not everyone, which is disappointing. So that’s what I’m here to talk about.

The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.

You can’t code review if you’re doing it live. So, ultimately the goal with code review is basically to improve the quality of your code.

So if you’re editorial, right, the idea is that you’re not going to push something out any sort of published articles without going through the copy editing phase, unless you care about money, in which case you don’t care.

You want to make sure the stuff you’re putting out is good quality, and that’s where code review is – that’s why it’s sort of nice to do.

The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.

So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.

And the secondary goal is you sort of becomes that you’re learning from each other as developers. It doesn’t necessarily have to be a junior developer passing off their work to a senior developer and them telling them basically everything they did wrong.

It can actually go the other way where a senior developer passes off their work to a junior developer and says here’s the code I’ve written,can you look it over and see what I’m doing?

It gives the junior developer an opportunity to look at how the code is being written by the senior developer and learn from them, right?

So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.

The other thing to sort of keep in mind is that code reviews shouldn’t be something else that you tack on. It’s part of the development process, right?

So it’s not something that you should consider a tedious thing that should be going on, it’s something that you should have built into your processes as part of your deployment, as part of your coding, so something you do on a regular basis.

There’s different ways you can do code review obviously. You can have a gatekeeper-type approach. Where you have one person who’s sort of like master of the code review, so every bit of code that gets written goes through that person.

So that person can be a senior person, can be a rotator role so all code goes to that person, they review it, send feedback and iterate on the code that way.

One flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.

You can do some things like peer review, where you have teams of developers put together, so one person is buddied up with another so any time a person needs feedback, anytime a person is finished working on a patch or working on a new feature they can pass it off to their fellow developer and say, hey can you give me feedback.

You can have a committee-based approach, where you have multiple people giving feedback on patches. If you’re using something like Git or GitHub you can use pull requests. GitHub makes it really easy to comment on code, and pull requests and commenting and so on.

You can also do pair programming, which I personally dislike, but it works for a lot of people if you’re into extreme programming or agile processes and stuff like that. You can have people working on code at the same time and the cool feature of that is that you’re essentially doing code review live because you’re questioning each other as you’re writing code.

One person types up something, the other person sort of questions: Okay, why did you write that?

There’s different points in time where you can actually use code review so you can actually start doing code review before writing a single piece of code and you’re essentially talking out the concepts with each other.

You know, we planned out the specs and functionality, we’ve thought about what my classes are going to look like, what my functions are going to look like.

So it’s a good opportunity to actually talk with you, what approach you’re taking to code review, to talk with the person with whom you’re doing the code review to see you know, does this make sense?

Obviously you do things like pre-commit reviews, look at patches, so before you even commit the code send the patch over, send over and review it that way.

It’s a great way for your team to actually write better code and build a more cohesive unit.

We also do post-commits, so once the changes are done, committed, you can review the pull request or the actual committed code.

You can also do post-deploy, so if you don’t actually have time, to do a full code review before pushing it out, you can still go back and do code review on stuff that’s pushed live and make changes over time.

The most important thing obviously is you got to find a flow that sort of works for your team.

So one flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.

Doesn’t necessarily have to be anything very specific. It can be sort of totally casual, like a conversation between two developers.

So it’s pretty important to find something that works for you. You also don’t need fancy tools, you don’t necessarily need to go out and get your own license of Phabricator, which is a code review tool that Facebook has built up.

To be honest, it can just be as simple as two developers passing around a patch to each other. Looking it over.

So it doesn’t have to be complex, but if you want it to be complex, you can.

But you can keep it simple, find something that works for you and so on. When it actually comes to doing the code review, there’s a few things to keep in mind.

Throw your ego out the door.

The most important thing, and this goes for both the person reviewing the code and the person receiving feedback is throw your ego out the door.

There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.

The reviewer is not smarter or dumber than the person whose code they’re reviewing. In the same sense, the person whose code is being reviewed they’re at the same level. So ego is not involved, it’s not supposed to be personal. It’s supposed to basically be about questioning the code, right?

Not questioning the person. So one thing that I usually try to keep in mind while I’m personally reviewing code is that I usually recommend to people is that when you’re phrasing your feedback never include the word “you” .

So it’s not YOUR code, it’s THE code. Right? So that takes away the personal aspect of it and it makes the reviewer feel less attacked.

Because getting your code reviewed can be a very scary thing, but it shouldn’t be.

You should get to a point, where you should actually be proud to have your code reviewed and proud of the code you’re presenting to your teammate, senior developer or boss and so on.

To show that this is the amazing thing that I’ve done, and you know what, I expect there to be flaws.

Chances are, there might not be, but you know, if there are issues with it, it’s something you know, the mistakes that you find, is something that I can learn from.

The other thing to sort of keep in mind, is that you as a reviewer want to be critical about things, right? So question the decision that the developer is making.

Why did they name that variable that way? Is that a valid variable name, right? Why is this function name so long? Can this be abstracted? Right? So design decisions like that can be a good way to root out potential problems in the code.

But obviously, you don’t want to get too caught up in the minor details, so getting caught up on spaces over tabs which we’ve had problems in the past with before, in VIP, where some developers would reject code commits for using space instead of tabs, you know that’s a minor implementation don’t get too caught up on that.

Point it out, but it’s not going to be a blocker. But it’s important that coding standards and best practices are still followed, so it’s important that your team is following those that in your reviews, you’re actually flagging those and so on.

The other thing to keep in mind is as a reviewer, don’t worry about catching everything. ‘Cause you’re not. I don’t mean to brag, but I think I’ve reviewed about 20,000 commits on VIP. Of the many commits that I’ve reviewed on VIP there’s been stuff that I’ve missed and that’s naturally going to happen.

Because manual code review is not going to be perfect. Automated code review is not going to be perfect.

There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.

Things will get missed, things will go live that will break your site. But that’s, an opportunity to learn from so the next time you review your code you’re going to be extra conscious about it and try to find that mistake that you made and try and prevent it from happening again.

So that’s the other thing as a reviewee, you should sort of keep in mind. When a mistake is found, and pointed out to you, you should try and avoid making that mistake again. It’s a very important thing. You should be using it as a learning opportunity, right?

If you are making the same mistake over and over again. Chances are there’s something wrong. Either with your processes or with how you’re developing. That’s something you should work to change.

Never focus on the negatives.

As a reviewer, if you find the same problems over and over again, that’s when you need to question what’s going on with this developer? Why are they not sort of picking up the problems that I’m seeing? Another thing I sort of do, and I mentioned this earlier with not making it personal, try to keep in mind try to stick to the positives, right?

Never focus on the negatives. What’s a good example? It’s important to start a phrase with: How can we do this better? Instead of this is dumb, this is stupid.

So again, avoiding the personal attacks, trying avoid getting too emotional about things and staying focused on this code could be optimized more instead of this code will break your site, things like that.

I think that just about covers it. That’s sort of one of the biggest things I wanted to go over. But also, I guess it’s ultimately important to find something that works for you.

Code review is, it’s something that’s near and dear to my heart because I’ve been doing it for the past three years as a reviewer, it’s the best way to learn best practices and learn new code.

I’ve actually learned more new WordPress functions by looking at other people’s code than I have through just following news and following WordPress codex and things like that.

So it’s a great opportunity for reviewers to sort of look at how other people code or how other people think when they’re approaching problems.

And as a reviewee, it’s a humbling experience and a great opportunity to learn. And ultimately, it’s a great way for your team to actually write better code and build a more cohesive unit to ultimately do cool stuff.

Thank you.

Q: It’s easy to think that if you don’t review everything, then you should just give up because if you’re not reviewing everything, then the problem is going to be in the spot you didn’t review.

So, I think that maybe some of the thought process behind not everyone here doing code reviews I think it’s something that I think everyone wants to do so I was wondering if you could provide tips is there any sort of lightweight code review process? Is there anything that doesn’t require every commit to be reviewed by somebody else?

A: So that’s where I would look at post-deploy commits or post-deploy reviews so reviews don’t necessarily have to block things from going out but you still take the opportunity to go back at some point.

Let’s say you have a work week, you set aside two hours in the week Friday or something where you as a team, get together and review each other’s code, and look at various commits and stuff.

So to give you an example, on WordPress.com, the platform, we have about a 120 or so developers. I may be fudging our numbers. We have a lot of developers pushing out code daily. We probably have anywhere from 60 to 100 to 200 commits going out every single day and we haven’t really actually found a good mix, or good flow for us what makes sense for a code review.

So we end up relying on post-deploy code reviews where the idea is certain developers will take some time on the side, a couple hours a day, a couple of hours a week to sort of look, skim through commits that people have done.

They’ll just look through the log to see a commit message or if there’s a particular feature they’re interested in or that they’ve worked on in the past to sort of give it a quick skim and see if there’s something that they can flag for the developer to work on.

So it doesn’t necessarily have to be a very time intensive or blocking process. Ideally, you want to get to a point where it does become integrated into your development flow but it doesn’t necessarily have to.

To be honest, spending even an hour a week is a perfect starting point.

Q: Is there a good size team for doing code review? Like if you have fewer people,are there better methods? Like for smaller teams, to do it so it’s not interfering, so it’s not just like back and forth constantly?

A: Again depends on your type of workflow and your team dynamic.

In that case, it’s like if you’re using like Git for example it’s a simple pull request is probably a great way to go.

If you’re working on a feature, send a pull request and have the guy sitting beside you say can you take a quick scan. Or if there are specific things that you are worried about, have them look it over and point out specific things.

Like I’m not really sure about this particular function, I’m not sure about how this class interacts with this feature, can you just take a look at it.

So it doesn’t necessarily have to be you’re reviewing the whole commit, just skimming through something and seeing if anything jumps out.

Participant: I have a small addition. So one thing that I find really helps out if you have a definition of the process so for example if you have code review documentation, like what kind of code structure you need to keep, templates defaults you need to use also speeds up a lot of reviews because you can automatically assume the person is following the structure, because they technically know about it.

The easy way to speed it up is to also just I mean ignore JavaScript and CSS, because if you have a lot you can just ignore CSS. If your quality assurance team passes it and it looks fine, also JavaScript if you really don’t have time.

A: I mean for CSS especially, as a code reviewer when I look at the VIP code, I basically ignore CSS, because from my perspective, I care more about the security and performance.

So you’re right, there are things you can sort of ignore, if you are a designer and like reviewing CSS, then go for it. But also, like you said, standards are really important, and processes are really important.

Especially, as you grow as a team, again doesn’t necessarily have to be super formal and super strict, but it helps to have some sort of definition in place so you can follow, your team knows what to do.

So they’re actually trying to have their code reviewed, instead of pushing it live.

Steph: Out of curiosity, how many people here have had Mo review their code?

Participant: He’s the best!

How many of you have had code rejected by me?

Participant: How many people want to beat Mo up after this meetup?

Participant:I’m in

Participant: Actually out code was reverted 2 min before the meetup.

What I usually tell people at like VIP workshops and stuff is that your ultimate goal should be to make me so happy that I would never want to revert that code ever.

We actually revert code once a day. The interesting thing is that if you have some sort of code review process, we actually notice when VIP’s adopt some sort of code review process, internally, so they have someone on their team review their code before it comes to us.

The quality, there’s a significant increase. The number of issues we have to flag, the number of reverts that actually end up happening to that code goes significantly down.

It’s a testament that code review can actually work and keep us happy and keep your code getting deployed much faster.

If you’re not on VIP, still a great opportunity to make sure your team is working together, make sure your team is writing good code. ‘Cause the last thing you want is to push out a security hole and all of a sudden has your homepage hacked the Syrian army or whatever.