Three weeks ago, in an attempt to make sure our test sites for Silicon Valley Code Camp did not get crawled and indexed for search, we checked into our source control a robots.txt file that looked like the following:

We should never have done that because it was somewhat like putting a loaded gun to our site.  The problem is, as stated in  http://www.robotstxt.org/robotstxt.html is that this blocks all search engines.  If we left the “/” out, it would have been correct and allowed all search crawlers.

The result of this is that all our 8 years of SEO (Search Engine Optimization) appears to be lost.  Now, when you search “Silicon Valley Code Camp”, you find several other people who have referenced us, some of our test sites that should never have been indexed and nothing else.  We fixed this 2 days ago however Google for example still returns results saying search blocked by a robots.txt file.  We are hoping (but not hopeful) that our old excellent search results will return.

WE NEED YOUR HELP!

We would really appreciate it if all you out there who have public web sites, put some kind of link out there to http://siliconvalley-codecamp.com.  That will help us to get some of our mojo back.  This year, we’ve done a lot to our web site to improve SEO.  For example, we have added the year to the URL, we have changed from URL’s like …/id=19934 to URL’s like http://www.siliconvalley-codecamp.com/Presenter/2013/Session/Douglas-Crockford-1124 which are much better at getting indexes. It’s very regrettable that we made such a blunder.

We are pleased to announce Silicon Valley Code Camp‘s 2013 dates. Please mark your calendar for our 8th Annual Event on October 5 & 6 at Foothill College in Los Altos, CA.

SVCC is the largest of its kind in the world. This free event is a great chance to network with other high caliber developers from the Bay Area. Last year we had over 200 awesome sessions, nearly 2,500 attendees, 300+ volunteers and 40+ sponsors. We are excited to continue the tradition and thank everyone for their support.

2013 is shaping up to be another great year. We already have 50+ sessions and several sponsors lined up. Even so, we need your help:

• Register ASAP to reserve your spot (last year registration was so successful that we may need to limit reservations).
• Tell your friends and coworkers about the event
• Know of any great speakers?  Let them know about us and encourage them to sign up as a speaker.
• Know any companies that would be great sponsors? We’d appreciate an introduction or have them call us directly at 1-866-385-4323.

We’re looking forward to another great event for the 8th year in a row! We hope you can make it.

Peter Kellner, Coordinator

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

While there is tons of in-person and online training to be a developer, when it comes time to become a manager we usually have little to no training. And you need that training because software people are not the easiest people to manage. It’s one of the realizations that Ron Lichty and Mickey Mantle came to appreciate and as a result, just wrote and published a book on the topic entitled, “Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams.”

I spoke with Ron Lichty at the 2012 Silicon Valley Code Camp conference about his book and his companion presentation, “Crash Course in Managing Software People and Teams.”

The number one rule of managing software teams is “you’ve got to connect with them and you have to gain their respect,” said Lichty.

One person in his presentation asked if you can be respected as a manager if you haven’t been a programmer first. Lichty doesn’t think it’s possible. Taking the leap from coder to manager means you have to leave the coding behind. We heard this time and again from different presenters. If you become a manager, you can’t continue to code.

“If you continue to try to code, you will code and not manage,” said Lichty.

The goal of managing software teams

“When you manage programmers you want two things,” said Lichty. “When they’re working on their own you want them to get into the zone. And you want all the rest of the world to disappear. You want them to climb into the microprocessor and just listen to the gates open and close. And then when they climb back out of it you want them to be part of a team and you want them to demonstrate teamwork and you want them to interact with each other.”

Doing that, admitted Lichty, is not easy.

Watch the video, especially until the end where Lichty has a great joke about the difference between introverted and extroverted programmers.

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

For years philosophers and religious icons have tried to tackle the great question, “What’s the meaning of life?” At the 2012 Silicon Valley Code Camp, I asked the incredibly geeky developers, “What’s the meaning of code?” Burn some incense and watch their answers.

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

There are three different types of dashboard design: strategic, tactical, and operational. As you move from strategic, to tactical, to operations, the level of detail in the dashboard goes up. Each serves a different purpose and a different audience, explained Lee Lukehart, Chief Data Visualist for SavvyData in his presentation “The Art of Dashboard Design” at the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.

Lukehart outlined the purpose of the three types of dashboards.

Strategic dashboard: Designed for executives to monitor ongoing trends on a year-over-year basis.  It’s often graphical. It’s not designed for real-time monitoring. For a dashboard to be strategic it needs a main metric you’re trying to meet, so that you can see if execution aligns with strategy.

Tactical dashboard: Built for managers to manage. Manage performance against preset target. It should be a tool to use for analysis and link results to actions. Plus the dashboard should help the manager discover problems and opportunities.

Operational dashboard: This is for the on-the-ground workers. It is where you see precise measurements in performance and other details. Information is often delivered in real time.

Avoid communications problems with effective data visualization

If not done right, dashboards can be confusing, boring, inaccurate, and worthless. Here’s how to avoid falling into that dashboard trap:

1. Know when not to use a certain visualization: Pie charts are abused. They’re not efficient. In many cases, just presenting a number will be more efficient. A table or list is often more preferable.
2. Know your data: Source the scope. Make sure your data is clean and complete. Avoid GIGO (garbage in garbage out).
3. Consider your audience: Understand their needs, objectives, and their familiarity with the communications tools. What is their level of knowledge and experience?
4. Determine the chart’s message or focus: Your dashboard is telling a story. Is it a ranking, a timeline, a category, proportion of whole, variance/deviation, distribution, correlation, or geospatial?
5. Select best chart type for the message
6. Construct data transforms as needed: Derive new data to tell the real story – aggregate, segment, factor, augment, find, and organize.
7. Conduct pre-flight checklist: Make sure you’ve taken the following into account before you release your dashboard to the world. Consider human factors, data issues, scaling, labeling, chart type choice, visual formatting, creating an über chart, and chart titling.

Human factors in visual perception

Before you let a dashboard out the door, think about how it will be perceived. Is your dashboard creating skewed results or results certain people can’t understand?

For example, take into consideration normal human optical perception issues, such as color blindness. If you’re going to be using the color red and green to show negative and positive results, also add other indicators like maybe a plus or minus sign, or an arrow going up or down. Also, take advantage of tools within Photoshop that shows how your dashboard will look to a color blind person.

Don’t intentionally or accidentally lie with your charts. One way to misinterpret values is to not show the zero level. All charts should show the zero level so you can see appropriate relations.

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Have you frozen during a technical interview? Have you been stumped by a question during a technical interview? You’re not alone. In fact, you’re everyone that’s been through a technical interview.

“No one has ever gotten every question correct,” said David McCarter, who led a presentation at the 2012 Silicon Valley Code Camp entitled, “Surviving the Technical Interview.”

McCarter advises that you come prepared for an interview. It sounds obvious, but he’s amazed at the number of interviewees that don’t research the company, the job, or study technical questions.

While you can’t know everything, you still need to practice and there are tons of technical questions online to get your chops up. The purpose of the technical interview is to see where you fit into the company’s skill sets, said McCarter.

Vocalize your thoughts

“Know what you don’t know, and admit it,” said McCarter.

Being upfront about where your knowledge exists and doesn’t exist is something the interviewer looks for. So be truthful. Even when you don’t know the answer, you can still show your process in how you’d go about solving the problem, or explain that you’ve been reading up on the topic even though you haven’t done it yourself.

Don’t be stumped by silly logical questions. They aren’t meant to be answered correctly. They’re designed to see how you go about problem solving, said McCarter.

McCarter quoted a question from Microsoft that asks, “Why are manhole covers round?” The point of the question is not to get a correct answer, but rather to hear how you think. So don’t internalize your thoughts when asked such a question. Be expressive.

McCarter recognizes that developers sometimes have a hard time expressing their thoughts. If that’s your normal behavior, put it aside for the interview and think out loud.

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

“It’s sometimes lonely in front of the computer,” admitted Mathias Brandewinder, lead for the San Francisco chapter of Bay .NET, a Bay Area user group for .NET developers. We spoke at the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.

Brandewinder joined the group and eventually ran a chapter of Bay .NET because he wanted to be on the forefront of .NET’s cutting edge technologies, and he also wanted to meet other fellow developers. The Bay Area, said Brandewinder, is admittedly not the most Microsoft-friendly area and finding other local .NET developers is really important. Plus, having the weekly education (Bay .NET meets four times a month) is critical because the .NET framework is huge and it’s changing very fast. To maintain his .NET chops, it’s important for Brandewinder to keep up with what’s important and not important.

Brandewinder ended up a .NET developer accidentally seven years ago. As a kid he wanted to be an architect. Software development filled that desire to create, but at a higher level at an even more experimental level, said Brandewinder, who hasn’t had a problem finding work ever since he became a .NET developer.

“I think [software development] is one of the most human people-engaging jobs around,” said Brandewinder. “I love talking with people who are expressing what they do, and you have to understand what they do and give them a great solution. It’s a very exciting problem.”

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Whether you’re a recruiter or not, we will at one time eventually have to hire someone. To learn more how engineers can help with the recruiting process, I attended a panel discussion entitled “Recruiting Hacks for Engineers” at the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California.

On the panel were:

• Dan Arkind (@danarkind), JobScore
• Aki Taha (@akitaha), Persona
• Jeff Winner, Cardspring
• Moderated by Pete Soderling (@petesoder), g33ktalk

Here are some highlights of the hacks, tips, and issues that came up in the conversation:

• Hiring managers and team managers recruit people. Recruiters just facilitate that process.
• A huge percentage of your working hours are going to be the people you’re working with so you should invest in who you work with. It will play into your happiness.
• If you want to start a company you need to show you can build a quality team to execute on the vision you have. Ideally you’ll have a history, but if you don’t you at least have to demonstrate an approach.
• If you want to be part of the culture of your organization, you have to be involved in recruiting.
• If you want to move into management, you have to show you know how to build a team.
• Recruiting is about putting people around you that you can learn from.
• You must make your company look attractive to other engineers. The goal is to attract them to you rather than having to compel them to come to you.
• If you have a product then your customers can be your employees. For example, if you have an API, you’re marketing to engineers to use the API, and then you can recruit from those engineer customers.
• A lot of engineering recruiting is about where you’re going, not where you are. You need a story that people are going to buy into as to where you’re going to go in the future.
• Bait them with a cool project. When exciting projects come up, use them as bait to attract new talent. Don’t give this to existing people. But that can become an issue to keep great talent. That’s the VP of engineering’s problem. Don’t bait and switch. You must deliver.
• It’s very difficult if not impossible to get engineers to give you referrals. Pose the referral request this way. Say that you have a particular project with this particular publisher. Do you have someone who would want to work on this?
• Ask your team members, “When you talk to your friends about us, what aspect do they get excited about?” If they’re having a hard time telling the company story, help them craft that story to tell their friends.
• Any good person your employees know, even if they just took another job, is a good referral.
• If you have a lot of trust, you can go through their contacts with them. But you have to be wary from being ID’ed as a slimy recruiter guy.
• All the best people you know and your colleagues know need to know your company’s story. When they become available, you want your company to be on their shortlist. That’s referral hiring.
• Instead of saying, can you refer a hire, say I’m looking for a person I can talk to about this problem. That connection is referral hiring. It can be a far more effective way to approach the problem.
• Most people ask the question, “What do you do?” Make sure your staff is comfortable with your stories. Situations pop up when you’re out and about.
• Recruiting takes a long time. There is no way to do recruiting that requires no effort. It requires effort and diligence.
• Half of the process of recruiting is that person is dying to work at your company. Engineers are trying to determine whether you’re a good enough coder to do the job.
• Pair coding in the interview process takes a lot of work. Sessions can be as long as three hours. That’s more important than all the other coding and technical questions. Ask if they have a github project. Then come over and work on their project with them. You learn a lot when you do pair coding. You learn what the potential hire is like to work with. You can see how they respond when they get frustrated. You can see their thought process and how they interact when they’re working.
• Beware of assessing an outside engineer about your knowledge. Figure out something that levels the playing field, rather than your specific knowledge. Don’t interview engineers to see if they know what you know. You’ll fail. That’s not an effective way to recruit people. You want to see if they know what they know really well. Will they be able to contribute and add value to your environment?
• The reason people get stressed out in an interview is they don’t know what’s going to happen. Instead, tell them what you’re going to do, so you get a relaxed person to assess.
• If you don’t get enthusiasm back on your vision, that’s a complete rejection. And if you do hire that person, the team will reject that person.
• What questions would you ask if you wanted a hard worker? What would you ask yourself?
• The way you recruit someone nobody knows is very different than recruiting someone that you or a team member knows well.
• Most important thing you can do is provide detailed written feedback after an interview. If you write things down you’ll be way ahead of others.
• Not everyone requires a long interview. Ask a series of binary (yes/no) questions to determine if they can go to the next level. If they answer no to all of them, move on. Higher speed and higher volume recruiting happens if you create a lot of knockout questions.
• No one who is talented will fill out a job application or a form online.
• If you find significant dishonesty on a resume, then become very wary.
• If you’re worried about something in a given interview, make sure you write that down and communicate it to the next person who is doing the interviewing. You want any of your worries dealt with in the interview process instead of the end when you’re all discussing the problem.
• Are you “open” to learning or do you want to learn? There’s a big difference.
• You can’t hire an OK person. It may be ok to lose the requirement. Just don’t hire someone if you don’t think they’ll be able to accomplish the task. It’ll set you up for failure as a manager.
• Highly favor people that have projects of their own, like their own GitHub project.

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

When you’re crafting a user interface (UI) you need to keep in mind that you’re trying to help users complete a daily task, said Uday Gajendar, Principal Product Designer for Citrix in our conversation at the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California.

There are some very basic do and don’t design fundamentals, said Gajendar. Don’t clutter up the screen with extraneous information and buttons, and do organize content through prioritization, hierarchy, color, typography, grid, and image elements that will help a user accomplish the tasks.

I asked Gajendar about a design philosophy that I’ve heard that says you should follow the rules of design and then break one rule severely. The rule should be broken so harshly that it’s obvious and the user readily sees it.

Gajendar agrees with that philosophy, but only after you understand design fundamentals. You must establish a baseline first. Once you understand, then you’ll know what rules to break.

The fundamentals of UI design is like a language, said Gajendar. You learn the grammar first, and then once you’ve mastered it you learn how to break the rules and create your own style.

Gajendar is all for breaking the rules. Just make sure you get the fundamentals right.

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

If you’re a web developer, you’re already a Windows 8 developer, said Jeremy Foster, Developer Evangelist on Windows 8 for Microsoft.

All your classic web development skills, such as HTML, CSS, and Javascript that you use to make an application can be used in the Windows 8 environment. There is a native element to it as well. You still will need to interact with elements of the device, and that’s where native programming comes in, but it’s all within your web development, said Foster.

To learn more, you can head to the Windows Dev site or to Foster’s blog, codefoster, and click on the “resources” tab.