Flash has been around for a long time and is installed and active on almost every browser, it seems most of the major video sites (e.g. YouTube) are currently using Flash as their RIA platform and the Flash 9 player has some new video/audio codec supports as well as support for ActionScript 3 that meets the ECMAScript specification (basically JavaScript).  Flash/Flex are mature, have solid tools, great documentation, a vibrant community and a huge installation base.  Flash/Flex has first mover advantage in the space.

Silverlight has just released their 1.0 and has gotten a ton of press.  From the development side, the combination of JavaScript and XML to create applications feels a lot like building applications with Flex.  Silverlight has also been designed to hook into .NET languages including IronRuby and IronPython and is really focusing on high quality audio and video experience.  For some cool examples of the technology check out a visual search engine, tafiti.com or the live streaming television broadcasting application LiveStation.  There is cross-browser and cross-platform support for the toolkit.  Not a huge community or install base just yet, but the technology is easy to install (about 4 MB download), easy to develop with, produces a fast and clean user experience, and the easy hook in to .NET languages plus its inevitable preloading into base Windows installs means that these communities will build up fast.

JavaFX is basically a nicer way to write applets.  There is no focus on offline applications, no focus on media, and a small effort on reducing download sizes.  Really nothing very interesting or new from what Java developers have had before.

It seems no one at Sun has ever read The 22 Immutable Laws of Marketing[1].  Let’s look at how many of the marketing laws Sun is violating.

• Law of Leadership – Being the first to market.  Sun actually had an opportunity 10 years ago when applets were starting to be built.  But while they may have been first to market for embedded applications in a browser, they let Adobe Flash be the first into the easy to install browser plugin for media applications.
• Law of Mind and Law of Perception – Java GUI applications are thought of as being big, slow, and ugly.  By including the term Java in the JavaFX name, people will clearly associate JavaFX applications with those terms as well.  Sun should rebrand.
• Law of the Ladder/Law of Duality - It is very hard to change market position.  And if you are not one of the top two players in a market, you need to find a new market.  JavaFX will not be in the top two, they need a new market.
• Law of Line Extension – Another problem with Java, the brand is so generic and means so many things that you don’t know what it is.  Java ME, Java SE, Java EE, JavaFX.  They all leverage the Java brand, but are all wildly different products.  (Sidenote, Sun’s changing their NASDAQ stock ticker symbol to JAVA continues these violations)
• Law of Resources – Adobe is going around with their Adobe AIR tour.  Microsoft is partnering with a bunch of big media players (e.g. check out http://silverlight.net/Showcase/ for samples for WWE, CBS, MLB) to work with Silverlight.  Sun spent some money on a press release.

For JavaFX to be a success, for their to be a community, I would recommend the following:

• Figure out what market segment you are solving problems for.  Do you want to be in the consumer RIA space or should the focus be on RIA applications developed within corporate intranets?  Where Adobe and Microsoft are focusing on the consumer space (explaining the drivers of media and online/offline play), perhaps Sun could focus on a different problem space with different needs.
• Stop with every name starting with the Java brand!  Get some differentiations with product names so people know what they are talking about.
• Come up with a real roadmap for the technology and let the development community know it is a core part of Sun’s development path, not a one off project.

[1] EVERYONE should own this book.  It’s $10, will take an hour to read, and will change your view of how you look at your company and business.

Bookmark to:

Hide Sites

So how should a developer operate as a CEO?  What do they need to think about.  What questions do they need to have answered?  Let’s discuss a couple required characteristics of a good CEO and then apply them to your career path.

SIDENOTE: Often, when we think of career growth, we equate growth to earning more money or a getting a better title.  These may be evidence of growth, but are not requirements.  Career growth may also involve trying new technologies, changing roles, or changing industries.  It may mean getting out of technology

Taking Responsibility

You, and only you, are responsible for your career path.  Accept this.  It is not your boss’s job to get you trained on new technologies, it is your responsibility to make this happen.  Figure out what you would like to learn and then ask your boss to help you make it happen.  If you do not take responsibility for asking, it is very unlikely that you will get what you want.  Regardless of whether your employer will pay for your education, do it anyhow.  Learn a new language (programming or foreign).  Read books and then apply them to your work.  Go to an interesting conference.  While it is definitely preferred for your boss to play a part in what languages you learn or what books you read, it is your responsibility not your boss’s to make it happen.

Determine Strengths

What are you good at doing?  Drucker posits that the only way to figure this out is by using feedback analysis.  He suggests that after every key decision or action that you make, write down what you expect the result to be and then review it in 9 to 12 months.  See if there are patterns between where you anticipated the results and where you did not.  From this feedback, figure out what you are good at and what you need to improve.  In addition, you may see things that you have no business doing.  For example, software developers often make atrocious project managers.  For some, this may because they lack training in the area; for others it may be that they lack the ability to develop an effective plan.  By looking at how you have done, you can see if consistent lack of planning is a problem and try to figure out if you can improve it or if you need others to help you with it.

In addition, look at how you operate outside of just writing code.  Take the opportunity to learn about things that extend outside your area of expertise.  Read books on marketing principles, go out on sales calls, take a basic class on accounting.  Improving yourself in non-technical areas will help you better understand demands on your co-workers and you may find that you have strengths in areas you never anticipated.

Know Your Core Values

Core values are the things that you feel are truly important to you; they are different than ethics.  Ethics relates to doing what is right.  Values relate to doing what you believe in.  For example, one of my key values is that I feel you should only hire the very best technical resources, that these resources should have problems explained to them and then should be empowered to make decisions as to how to best solve the problems.  The corporation I was working for decided to take a different philosophy where the business users were more responsible for deciding how to solve the problem.  That may be the right decision for the organization, but it violated my personal values.  Other examples of value decisions a company will need to make may include:

• The level of R&D investment to make
• Use and contribution to open source software
• Whether people should be compensated by stock options or by cash
• What accounting rules to use to recognize revenue
• Support for telecommuting

Just because you may disagree with a company’s values does not mean it is a “bad” company.  But trying to stay in an organization that has values that conflict with your values will only lead to frustration.

Planning for the Future

Take some time to think about what you where you want to be in five years.  Figure out what skills and experiences you will need to achieve this goal.  Write down what it will take and review the list regularly.  Another great suggestion that Drucker has is to have a hobby.  You never know if that hobby will lead to a second career.  After twenty years working with technology, you may lose your passion and you may be prefer a change in career direction.  By encouraging other interests, you may find that your desired career path is no longer in technology but is in another area

Bookmark to:

Hide Sites

At my previous employer, we (by we, I mean a bunch of other smart people on my team) have built out a framework to manage this sort of distributed programming.  I advocated strongly that the organization should open source the project using many of the reasons discussed earlier.  Now that I have left, I hope someone can pick up the torch and get the MapReduce project released.

Bookmark to:

Hide Sites

How Can You Be Marketing A Development Team?

First, everyone should take an hour and read The 22 Immutable Laws of Marketing.  I’ll wait…..

Wasn’t that an hour well spent.  Okay, now that we know what marketing is and what to think about when building a marketing plan, we can dig into marketing your IT team.

When you recruit, you are selling a product.  To be precise, you need to sell to the consumer (the qualified job candidate) that your product is one they should buy (they should work for you rather than working for someone else).  From our previous discussion on building teams, I know that you are looking to hire great developers so they will shortly have multiple job offers.  Heck, they may already have a job and not be actively looking (lack of awareness of your product).  So your competition is fierce.  One way to compete is on price (in this example, by offering a higher salary).  But most discerning consumers are also concerned about the quality of the good and how satisfied they will be with it.  This is where your marketing plan kicks in.

What Must Our Marketing Plan Communicate

We want our consumers, potential hires, to know:

• That a stellar product exists in the form of a great IT team
• That it is available to them as positions are available
• That they will be satisfied with their purchase as others who have bought in continue to enjoy their work.

So how can we let our customers know about our wonderful product.  Well the traditional way is by posting classified ads online.  While that may let some people know of the availability, it will attract only those that are looking for jobs (missing candidates that do not know they should be looking) and does nothing to help with the other two bullet points.

How Does Open Source Help

If your company either sponsors an interesting open source project or, at a minimum, encourages developers to submit patches and improvements back to open source projects, it can serve to notify the development community about what your team is doing and the quality of work that is going on.  It makes people realize that there is something interesting brewing in your company and can easily drive people to your site (a fair percentage of requests to Health Market Science’s home page come from http://jackcess.sourceforge.net/).

Now Leverage Your Superstars

Now that people can look at a bit of your work, you can encourage your team to speak at conferences and user groups about the technologies.  Again, it helps to spread the brand name for your IT team, make potential candidates aware of what you are doing, is rewarding to your current team, and costs little to nothing.

In a future blog post, I’ll talk about how to find projects to open source and how to try and sell it to superiors (I know that I have not been as successful in the selling as I would have hoped, but I do believe it matters). 

Bookmark to:

Hide Sites

When considering joining a startup, here are the questions that I want to satisfactorily answer before making a decision.

Position Questions

1. Will I be able to effectively partner with the other team members?
2. Will I get along personally and professionally with the other team members?
3. Do the other team members have complementary qualities to me or will we all be trying to fill the same? 
4. Can we develop a shared vision?
5. Can we disagree in a constructive manner?
6. How will I get started at the position?  Would there be a trial period?
7. What will be my roles and responsibilities in the short, mid, and long term?
8. What will I be responsible for and what will other team members be responsible for?
9. How much influence will I have over product and company direction?

Compensation Questions

1. How will I be compensated?  How much cash (both deferred and non-deferred), equity, and bonuses.
2. Is the equity being offered fair for my position and the state of the company (take a look at this hiring plan equity suggestion from Venture Hacks)
3. How many outstanding shares are there and how many have been dispensed?
4. How long will salary be deferred?

Company Questions

1. Who do you think your competition is, both in the short and long term?
2. How will the company differentiate itself from these competitors?
3. What is the marketing plan to raise awareness of the product?
4. What is the product development plan?
5. When will releases occur and what will be in them? 
6. Are the schedules reasonable from both a technology and market view?
7. What is the upside opportunity for the company?  How likely is that upside to be realized?
8. How much protectable IP will be available?
9. How good is the current team?
10. What gaps exist on the team and when will they be filled in (e.g. VP Marketing)?
11. Where will the company be located and is there a plan to move as we grow?
12. How susceptible is the company to changing fads in the VC marketplace?

Financial Questions

1. What is the financial projections for the company? 
2. What will the cap tables look like after all investment is in?
3. What will be my equity position, taking into account preferred shares already granted and those that are planned for future investment?
4. What are the revenue opportunities and when will we start seeing revenue?
5. What is the proposed exit time frame?
6. Who would be potential acquirors?

Introspective Questions

1. Do I feel comfortable with the timing of taking this position?
2. Do I have the support from my family?
3. Am I more scared of failing or of missing a great opportunity?

Bookmark to:

Hide Sites

First, you have the Innovator’s Dilemma (any current or potential entrepreneur NEEDS to read this book) problem; big companies are great at producing evolutionary improvements to technology, but have a really, really hard time creating innovative products.  This stems from a couple of factors including:

1. Great Expectations Lead to a Fear of Failure– Google is expected to release great products.  If they try to release an innovative social network and it bombs, just think of the newspaper headlines.  “A Real Google Bomb” .  ”Google Losing the Magic Touch”.  Everything has to be damn near perfect before you can go into a public beta.  Also, the application has to be comprehensive from day one.  Myspace.com had the luxury of focusing on making a product useful for bands to self-promote before being a place for any idiot to create a site.  Facebook.com could focus on making a place to try to scope out cute chicks before becoming a development platform.  A Yahoo or Google would not have the luxury of having those growing pains.
2. Competing Priorities – Think about the now famous Peanut Butter Memo at Yahoo.  Even at a large company, there are only so many projects that can be a priority for development, marketing, corporate, and operations.  To justify the investment costs across the company for a major new innovative product is often too risky.  For the News Corp/NBC Universal video company, the competing priorities that the focus is trying to maintain a legacy business model (television sponsored by advertising) as opposed to a better user experience.
3. Legacy Systems – Both Yahoo and Google have social networks already.  How do they put something new out there without pissing off legacy customers?  Very, very hard (maybe impossible) to do.
4. Bureaucracy  – At any company, the bigger it gets, the more approvals it takes to make any kind of product or release.  These take time and make it harder to respond to customer needs.  The impact when trying to build a community site is gigantic.  Unless you can be nimble enough to quickly respond to the community, you may never reach critical mass.
5. Too Many Cooks – I think this could be a huge issue for the News Corp./NBC Universal site, but it is a factor with any big company.  When too many people feel that they need to add their input about product direction, it tends to slow down development cycles and reduce innovation potential.

If a next generation social network is to be built, my bet would be on Google/Yahoo acquiring it (a la YouTube) rather than building it themselves.

Bookmark to:

Hide Sites

So the question becomes how do we avoid chumps during the hiring process.  When looking for a candidate, I am really evaluating across five criteria.

• Are they intelligent? 
• Are they curious?
• Can they get stuff done?
• Will they fit into the team?
• Do they have the right experience?

SIDENOTE:  Let me give some credit to others right away.  I am heavily influenced by the author’s in the references section.  Joel has clearly described the need to find smart people that get stuff done.  DeMarco (no relation) and Lister talk at length about fit into the team.  You should read their work.

Let’s dive deeper into these questions.

Are They Intelligent?

Do they have the raw brainpower to hold everything in their head to be successful at their job.  When you are designing a system, you have a million different things that you need to think about.  How should it work?  How do I need to approach the problem?  What are the appropriate technologies to use?  Where will the system need to go?  How should the system be architected?  What are the pertinent design patterns?  How can I test this?  For complicated applications, these are hard questions to answer.  It requires experience, good judgement, good analytical and problem solving skills, the ability to learn new skills (both technical and domain specific), an understanding of the appropriate tools, and the ability to hold conflicting ideas in your head at the same time.  Can they propose solutions and handle other intelligent people challenging them?  The people that I am looking for love to be challenged by other smart people.

SIDENOTE:  Do not confuse intelligence and education.  Some of the best developers never graduated from college and lots of bad programmers have Comp Sci degrees.  Undergraduate and graduate degrees prove an individual is educated but ARE NOT NECESSARILY a sign of effective intelligence.  Then again, I do not know many stupid Ph.Ds from MIT.

Are They Curious?

Have they ever decompiled a Java class to figure out what was going on.  Have they downloaded the source for an open source project to help with debugging?  Do they tinker with different technologies at home?  Do they read a lot?  Will they dig deep to figure out why something is working or are they satisfied just getting something that passes basic tests.  I am looking for people who want to understand what the business problem we are trying to solve is and figure out the best way to accomplish it.  I am not looking for automatons that will just execute whatever they are told to do.  Curious people crave a better understanding of the world and make wonderfully innovative engineers.

Can They Get Stuff Done?

Copied straight from Joel Spolsky…Sometimes smart and curious people spend so much time analyzing what is the best way to do something that they ignore the importance of getting SOMETHING done.  There is a saying that delivering 80% today is better than delivering 100% never.  Has the candidate ever shipped software to production or managed an operational system (you would be amazed at the number of people that have never had their code in a real production system)?  Have they ever had to deliver under pressure.  Do they like the pressure?  Do they like the sense of accomplishment?  Will they not rest until the problem is solved?  This tends to be an area where many people with strong academic backgrounds fall down in the interview process.  The mentality in a corporate software environment is very different than the attitude and pressures in an academic environment.

Will They Fit Into the Team?

In the book Peopleware, Tom DeMarco (not related, he spells his name wrong) and Tim Lister describe a candidate that did not get a job at one software company.  The candidate was qualified, but the interviewers did not feel he would fit on the team because they did not think he would find the concept of lips on a chicken hysterical as they all did.  An arbitrary criteria, but if someone will not mesh in the team dynamic, they will be a cancer and will drag down the overall team performance.  When looking for fit, I am looking both at personality and experience.  When evaluating the candidate, would you be excited about working with them?  Why or why not?  Will their experiences (both at work and off hours) complement the experiences of the team.  Will they be excited to learn from others?

Do They Have The Right Experience?

Notice that the experience question is the last of the criteria for evaluation.  Appropriate experience does matter, but it is probably the ONLY one of the criteria that an employee can improve on over time. At HMS, we use Java 5 (soon to be Java 6), JBoss 4, and Maven 2.  Does it matter if an incoming employee has worked with any of these technologies?  Should I reject a good candidate just because he hasn’t gone through the pain of building a multi-POM project?  No way.  A smart, curious person that gets along with the team and wants to do a good job can LEARN these tools.  In three months, they’ll be completely up to speed.  I’m not hiring a three month contractor, I’m making an investment in a full-time hire that hopefully will be around for years. 

SIDENOTE:  There are some positions where experience is more important, but in general it is the most overrated criteria

Now that we know what we are looking for, let’s figure out how to answer these questions.

Step One: Reading the Resume

First step at eliminating the chumps comes when looking at the resume.  Some things that I look for:

• Is there anything interesting on the resume that I would like to talk more about with the candidate.  An interesting project or an interesting technology.  A big achievement.  When you see a resume and all of the accomplishments seem like they should have taken less than a day to complete (e.g. used JDBC to save data in a relational database), that means the candidate is probably failing one or more of the intelligence, curiosity, or getting stuff done questions.  For recent college graduates/intern candidates, I like to look at what classes they took or what research they have done.
• Have they done different things, both on and off the job.  I love seeing resumes for people where they have worked/studied in a wide range of things.  Resumes where the person has been just working on one technology, on one platform means that person is probably failing the curiosity test.
• Have they advanced in their career.  Smart people who get stuff done tend to not be satisfied with their position and their projects for very long. 
• Did the person put some time into the resume?  Grammatical errors or spelling errors are a big problem for me.

Step Two: The Phone Interview

So the person’s resume is interesting enough to move on to the next step, the phone screen.  This is a basic sniff test to decide if the candidate is a chump or if we want to invest serious time in them.  Phone interviews should generally last 10-15 minutes and are meant to screen out candidates who clearly fail one or more of the criteria.  In a phone screen, I try to find out if they have a good knowledge of the technology that they have been working on and an idea of what they actually did on the projects that they have been working on.  Sample questions may be:

• Simple Technical Question like “What’s the difference between a list and a set?” or “What’s the difference between an abstract class and an interface?”  If a software candidate cannot get that right, they are probably not going to get through the rest of the interview.
• Digging Deeper Question like “What was the biggest challenge you faced on your last project?” or “What do you enjoy the most about your last few projects?” or “What do you wish you had done differently/better on your last project?”   The goal of these types of questions is to get a deeper understanding of what they have been doing.  Good candidates tend to have interesting answers to these questions.
• Awareness Question like “Are there any technologies you would like to work with and why?” or  ”Has there been any book/website/blog that has made you think differently about how you should work?”  These questions tend to shed light on the curiosity, intelligence, and motivation of the candidate.

Remember the point of the phone interview is to screen out chumps as quickly as possible, not to make a final decision on the candidate.  Fifteen minutes tends to be sufficient to make a decision whether you would never want to work with this person or whether it is worthwhile to bring someone in for a deeper interview. 

Step Three: The Face-to-Face Interview

The goal of the face-to-face interview is to discover whether we can affirmatively answer all five of the questions posed for this candidate.  When conducting the interview, you should be thinking about how a candidate’s response to your questions can help you answer your questions.  I like interviews to be conducted with 1-3 interviewers (ideally 2 people) talking with the candidate in a relatively informal setting for about an hour.  At least three groups should meet with the candidate to get a decent range of opinions.  It is better if the groups co-ordinate beforehand and decide on what questions or areas each will explore to minimize overlap. 

I usually like to start with simpler questions to get the candidate talking and  then move onto harder questions.  In the course of the interview, the candidate should actually have to demonstrate how they would do the job.  For a developer job, a candidate MUST write code.  Watching how someone writes code can give enormous insight into their intelligence, creativity, and ability to work with others.  How long it takes a candidate to answer a code/design question is usually a great tip off to the quality of the developer.  Candidates that quickly and accurately answer questions tend to be much better than candidates who struggle but eventually get the answer (SIDENOTE:  Be aware of the candidate’s experience level though, as that can impact the time depending on the complexity of the problem).  Similarly, a business analyst should be given a task to write down requirements for a given system and a project manager should have to build out a schedule.

Thought questions like “How many gas stations are there in Philadelphia?” can also be good.  They can give great insight into how a candidate thinks about solving a problem, but make sure that the question isn’t a “trick” question and that the focus is on the decision making process, not on the answer.

Coming up with good questions takes practice, as you do more and more interviews, it becomes easier.  Just remember, you are trying to decide if the candidate meets all of the five criteria and your questions should help you figure that out.  Remember, the goal of the interview is for you to make a Yes or No decision.  If you are wavering in between, try to figure out what area you are wavering on and dive deeper into that area.  The worst thing that can happen is you leave an interview not having effectively answered the five questions.

If it is clear to the interviewers that this candidate will fall short of our criteria, they should politely end the interview.  There is no point in wasting the candidate’s time or our time if the answer is going to be a no.

Step Four: Decision Time

When it comes time to make a decision, all of the team members that have interviewed the candidate should talk.  Generally I find people to be in one of four camps, Strong No, Weak No, Weak Yes, Strong Yes.  For a candidate to be hired, at least one person MUST be a Strong Yes and NO ONE may be a Strong No.  At least one of the interviewers, and usually more than one, should love the candidate and be demanding for that candidate to be put on their team.  For people who are Weak Yeses or Weak Nos, I like to dig into their concerns.  What didn’t they love about the candidate?  Did other people see the same weaknesses?  The goal is to come to an honest consensus on the candidate.  If anyone is a Strong No, it is a No Hire.  If there is no consensus, it is a No Hire.  If everyone is a Weak Yes on a candidate, it is a No Hire (although it may also be a sign that the questions that were asked did not do a good job in answering the five criteria about the candidate).  The goal is to get great hires and avoid chumps; it is not a time to take big risks.

Important Lesson: WHEN IN DOUBT, DO NOT HIRE!!!

Hiring great people and avoiding chumps is hard work.  It takes a lot of time and effort and can be frustrating, but it is essential to have a great performing team.

Some Questions

You are an elitist prick.  Why would anyone want to work with you?

You are right.  I am elitist.  I spend more of my waking time working than I do with my family, my friends, or my hobbies.  I want my workplace to be filled with people that I respect and that I enjoy working with.  I am lucky enough to play a role in deciding who I will work with.  I want those people to meet my criteria.  But in my experience the people that do meet the criteria WANT to work with other, similarly talented people.

Won’t you miss some good people this way?

Absolutely.  The system that I have described is designed to minimize false positives (hiring chumps) at the expensive of having false negatives (not hiring someone who would be good).

Isn’t it hard to grow your team?

Yes it is.  We go through a lot of resumes and candidates before we make a hire.  This makes recruiters unhappy.  But it is not my job to keep recruiters happy, it is my job to build the best team possible.

I interviewed with you, but you didn’t hire me.  Does that mean you think I’m a chump?

Not necessarily. It just means that we weren’t positive that you were great.  We have been wrong before, just chalk it up to us being wrong again.

References

Joel Spolsky’s Guerrilla Guide to Interviewing

Peopleware by Tom De Marco and Tim Lister

Good to Great by Tom Collins

Edited for grammar improvements, 3/30/2008

Bookmark to:

Hide Sites

In any rapidly growing organization, the rate limiting factor for growth can often be limitations on how fast you can find high quality people.  Losing a good team member just makes this a little bit harder.  If you are a manager, it is your PRIMARY responsibility to keep your team motivated.  Remember, you have already read Joel’s Guerrila Guide to Hiring, you have great team players, now the key is to keep them.

So in the spirit of Anti-Patterns, here is what not to do to keep your team intact drawing from my years of experience in the startup technology game.

I’m sure that there are more I can come up with, but dwelling on Anti-Patterns for too long is unhealthy.

Side Note:  Speaking of Anti-Patterns and losing good people, here is a great article on Java Exception Handling Anti-Patterns from a developer who used to work for me and who I drove out , Tim McCune.

Bookmark to:

Hide Sites

After reading Brad Feld’s Me.dium post, I took some time to play around with their Firefox plugin.  Short version, they track what page your browser is on and graphically display other people that are viewing that site or similar sites.  You can then chat (directly to friends or by “shoutout” to the public) with others that are looking at the same stuff.

The GUI is pretty slick.  Very responsive and fast with an interesting view on showing your network.  One of the designers talks about the thought that went into conveying the complex information.  Kudos to the developers and designers.

However, I just did not feel comfortable talking with other people or having other people see my name associated with what I was reading.  I felt it would be like if the librarian gave someone my reading list or if iTunes broadcast every song that I played (I hate to admit that I like the Dixie Chicks).

I use sites like del.icio.us to track my bookmarks and do not mind making things public, but it just felt a little too Big Brotherish for me.

Bookmark to:

Hide Sites

Kudos to them for taking the time to listen to their users.

Bookmark to:

Hide Sites