Monthly Archives: August 2007

Thoughts on Process: Automation (and examples)

If a process, or part of a process, can be automated it should be. For example, in a project at work, part of our process is to make sure that every dialog present in the English resources of an MFC application is also present in all the other dialogs. We do this manually by loading each language into the app and triggering every dialog. This is tedious, time-consuming, and error-prone. Did I mention we have 12 languages?

A better way would be to have a utility that quickly parses a resource file and extracts the dialog names and compares that list to all the other languages. It could even by expanded to do a control-by-control comparison to make sure all of those were present.

At some point, of course, the dialogs have to be visually inspected for spacing issues in other languages, but for an automated check, it can find the most common errors pretty quickly.

I am a huge fan of automating processes like this. There’s no reason to waste brainpower on highly-repetitive tasks. Even if it takes me a whole day to write a tool, it’s usually worth it.

Examples of automated processes:

  • Build process – if you’re building and packaging your product manually, you’re doing it wrong. All modern environments include command-line, scriptable components. When we build our flagship product, I type “make” and ten minutes later there’s a setup.exe in a distribution folder for our team.
  • Unit testing – Unit testing suites are usually automated to some degree (you hit a button, all tests run), but it can be taken further by running them during builds or as part of a continuous integration server.
  • Documentation/Change-logs – whenever we produce a new build, we send out an e-mail to internal staff about the changes. These are usually culled from the check-in comments in subversion. It’s a manual process. It might be nice to automatically dump them to a file, which can then be edited instead of written from scratch.
  • Code checks – this can encompass almost anything, but having static analysis tools is invaluable. Like the utility that I mentioned earlier to compare resource files across all the languages we support, it can save tons of manual, “stupid” labor.
  • Loading source onto a new machine – How long does it take to get up and running on a new machine? Admittedly, you shouldn’t be switching machines all THAT often, but when you do how easy is it to grab the source and start debugging? Are all the required libraries and tools in source control and automatically configured by build scripts?
  • E-mail – If you’re like me, you get scores if not hundreds of e-mails a day. How are you organizing, sorting, responding, ignoring, deleting them? Setup filters to put them into different folders, highlight or tag them when certain keywords appear. Also, get Google Desktop Search or Windows Desktop Search. I like both of them, but I’m currently using Google’s version. I may switch back in a while.
  • Bug reporting – While not strictly about automation, I think it’s close enough. Reporting bugs and code changes in a text file is good for a while–if you’re the only one working, and you have a small number of them to deal with. Once you start involving more programmers, and perhaps a manager who wants to see some basic reports, the text file doesn’t cut it. Get a simple bug reporting tool. I use BugTracker.Net because it’s easy, simple and does exactly what we need with minimum fuss. How do I know what to work on? I open up a web page and it tells me. I’ve automated not only some manual labor, but also some needless thought processes.
  • Calendaring – Do you need to write a weekly report for your manager? Keep track of employee’s vacation schedules? Use Outlook’s (or whatever PIM you choose) task list and calendar for anything you need to remember about a specific date. Set reminders for when you need to think about them, and then forget about them.
  • Data production – if you’re in a production environment generating data that needs to be analyzed, create tools to do as much of it as possible. Of course, the tools need to be checked for correctness, but once you’re confident, do it and don’t look back.

There are many, many ways you can optimize, reduce, and automated the work you’re doing. Remember, the whole point is to get rid of the “dumb” work and let yourself concentrate on the important, creative things.

Technorati Tags: , , , , , , ,


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Promoting your blog

Peter Bromberg has a great checklist of things you can do to promote your blog. It took a while, but I went through almost all of them. We’ll see if it pays off!

Technorati Tags: ,


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

Thoughts on Process: How much is enough

I’ve been thinking a lot about process lately, specifically how much process is enough, and how to automate things I do regularly. First of all, I think I’m lucky to work in a place that does not have a burdensome process in order to get anything done.

At its core, process is necessary because we as humans make mistakes quite easily. A process is a set of well-known, written guidelines to follow when doing a task.

I say written, though quite a few processes are mental, because if a process isn’t formalized, it’s more “This-is-how-we-do-things” than a real process. Process has to be repeatable by not only yourself, but by others.

I’m not the kind of person who really seeks after process formalization. I avoid paperwork like the plague, but even I admit that at some point you need to formalize at least something. The real question is how much process is enough. The answer is: exactly as much as you need and no more. The problem is, that amount is very difficult to find. I almost always err on the side of not adding overhead to anything until I see a clear need.

Process should not be added unless there is a clear and quantifiable benefit to the project. And I think the people who carry about the process should be the ones to judge if there is a benefit. Of course, there are exceptions, but I think for standard software projects, less is definitely more.

As an example, suppose I need bug tracking software. I find one that I like, and install it and we use it — it’s perfect for our situation. Along comes somebody else and insists that we switch to the corporate policy, even though my group does nothing like the rest of the company. It’s also a larger, more complicated program, and my group loses control of it. (If this sounds like a real situation, it almost is).

When confronted with this hypothetical, you should be asking yourselves, but what do I benefit? What does my team benefit? What does the product benefit? I do NOT ask what does the company benefit–why does that matter? If it doesn’t help our product and makes our jobs slightly more difficult, then the detriment is worse than any supposed benefit to the company as a whole. I’m sure you could argue this example both ways (for example, if support is an issue, maybe the company is right), but the point is to avoid processes and standards for the sake of themselves.

Here’s the key: Another word for process should be simplification. Having a process should simplify life, even if the actual steps are complicated. It’s the fact they’re written down, or we have automated tools, or that’s it formalized into a printed sheet of paper on a binder at our desk that simplifies it–it takes away our ability to inject mistakes. Does this make us mindless drones? For this process, yes!, but the point is that we shouldn’t be thinking about this anyway! Our minds should be hard at work creating something NEW. The process exists to make sure things go exactly as they need to, for the express purpose of freeing our minds to work on more interesting things.

A good process that I recently had to formalize was our final release build of our flagship product. After too many false starts, we realized that there were too many people, too many resources from various sources, and it was impossible to coordinate it all in someone’s mind. We needed a simple process to be signed off on. So a written checklist was created. We won’t use this for every build–just those that go to the customer. It’s simple, it works, it lets us worry about things worth worrying about.

I’ll talk about automation in another post…

Technorati Tags: , , ,


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

More on Google interview

This a follow-up to my previous post about my interview process with Google. Once a post gets as long as that one did, I’m sure to forget to say some things. Rather than updating that post, I thought I had enough new to say to warrant a new post.

First is the picture I got of their development process. There are plenty of other places on the Internet about their development process, so I won’t go into detail about what they told me–it pretty much matches up with the available information. It really sounds like they try to match the amount of process required to the specific project at hand. Projects with a huge public impact have lots of process (Google’s front page, indexing, etc.), while those that are newer and much lower impact (stuff in the Labs section, and even graduates of the Labs) have a much more flexible, agile process, designed to get improvements out the door very quickly. I like that–no mandatory bureaucracy where it doesn’t make sense.

Aside from process, however, it seems that they are very intent on giving developers an environment designed to help them succeed. From what I understood, the company actively tries to remove stupid barriers to productivity (needless paperwork, poor IT, bad workstations) and give you whatever you need to do your job how you think best. Obviously, there are rules and standards, but it just sounded more flexible. It really sounded like an ideal development environment: Obstacles removed, needs granted. Now, how much of that is the official “show” they put on for all interviews, who knows, but Google is obviously doing something right.

Bottom-line is that Google is a company of engineers for engineers. They’re the ones in charge of what the company does. That is a very nice place to be if you love coding.

Also, I should mention that the Google Boston office is MUCH smaller than their Mountain View headquarters. The way things are done, while it will still be “Googly”, will most likely have a different feel and pace than at headquarters. I had read many reports on the web about how people worked late hours, on weekends, and basically sacrificed their lives for the company. I did NOT get that impression in Boston. They were definitely smart and very hard working, but it sounded more like the company was flexible and if you got your work done, who cares? (That’s the way things ought to be done for sufficiently self-motivated employees). I did ask about inordinate over-time (mistake on my part?) and work-life balance and I came away with a satisfactory impression. Whether this means Boston is special, or the accounts I read on the Internet were not representative, I don’t know. Probably a lot of the latter, for sure.

I also wanted to address my final link in my last post. I know it can be a little disappointing to read that kind of post and realize it’s not talking about you, because you’re interviewing for jobs. I wouldn’t take it too literally. Maybe my link text is a little black and white. I think the principle is definitely valid, though. The better you are, the more freedom you have to choose where you work and what you work on and the less chance your going to fall into a company’s hiring process. It’s really more about statistics from a company’s point of view of finding the best, not necessarily for individuals.

Hopefully, that’s all I have to say on the subject, but if you have questions, just leave them in the comments and I’ll try to answer them!


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at:

My interview experience with Google

(See also part 2 of this article).

A few months ago I received an e-mail from a recruiter at Google asking for an opportunity to talk to me about available development positions. Needless to say, I was pretty excited. I’m fairly happy in my current job, but–it’s GOOGLE. You don’t say no to an interview opportunity at Google.

Like this article? Check out my latest book, Writing High-Performance .NET Code.

I’m writing this account in order to contribute to the meager resources available on the Internet about the Google interview experience. I signed an NDA, so I’m not going to say what the specific questions were, but I think I can give a pretty good idea of my experience. I apologize right now for the length.

I traded a few e-mails with a recruiter in Mountain View. I had a phone conversation with him, wherein he asked me general questions about my skills, desired work locations (giving me a choice of Santa Monica, Mountain View, and Boston). I have no desire to live in California, so I chose Boston. I was then passed to another recruiter, who setup a phone interview with an engineer in Mountain View. There was a false start, when they couldn’t do the interview at the original time, so we postponed.

The phone interview went very quickly. He was very nice and asked about my specific talents, things I enjoy doing, and projects I’d worked on–especially those I listed on my resume. He asked about the ray tracer I wrote in college, since he had an interest in that. He also asked some general questions about the stuff I do for work. Then he got into the technical question. It was an interesting problem, and I asked follow-up questions, talked out loud, wrote things down in front of me (and told him what I was writing and why). I immediately thought of the naive solution–always a good place to start. He was interested in the asymptotic complexity. I knew there were better ways of doing it, so I started thinking of optimizations to the algorithm, trying to come up with ways of caching information, reusing previously-computed values, etc. He gave me some gentle prodding, and I think I understood immediately where he was going. I answered the question fairly well, I though.

And that was it–just a single question. I was surprised. The entire thing lasted less than 30 minutes. I was almost disappointed, and thought–“well, that’s that–I won’t hear back.” I really wasn’t expecting any follow-up.

The next week, I got an e-mail from my recruiter who said I had impressed and was going to get the opportunity for an in-person interview in Boston! They hooked me up to a travel coordinator, as well as the recruiter in Boston.

Very exciting. I had a convenient time to go, so I set that up, took time off from work and went up to Boston, staying in the Cambridge Marriott. Very nice hotel. 40″ flat screen TV in the room ( which I never turned on). All expenses paid for, of course. :) I did have to pay for hotel and food up front, and save the receipts. (And yes, I promptly received a reimbursement check from them a few weeks after I sent them in.)

I arrived on Monday afternoon, figured out Logan International (a very confusing airport, I thought), and got myself to Cambridge, in the heart of MIT, an hour or so later. I checked in, then went walking. I found the building Google is in on the very next block from the hotel. They have a floor in a building that MIT leases to startups, tech incubators, and the like. There are plenty of news articles about the Google Boston office–just…you know, Google for them.

I walked past the ultimate geek bookstore–

Quantum Books. Discount tech books. COOL. I would definitely have to stop there later. Then I got some cheap, awful Chinese food at the food court

right under the hotel. Why? When I could go out on Google’s dime? I think I was just tired and wanted to get back to the hotel soon and start studying.

I ate dinner in the room, took pictures of the wonderful view of the Boston skyline.

Boston Skyline (Day)

Boston Skyline (night)

Studying

What did I study? I brought two books with me: Robert Sedgewick’s Algorithms in C++, and a C++ reference manual. I went over advanced C++ topics, STL, simple sorting and searching algorithms, properties of graphs, big-O, and anything else that popped into my head.

By far the most valuable thing I did was write out algorithms before-hand. I picked something and wrote it out by hand in a notebook. It was hard going at first, but I knew it was the best thing I could do to prepare. I did selection and insertion sort in both array and list form. I did string reversal, bit reversal, bit counting, and binary search. All by hand, without looking in a book at all. As well you might know those simple algorithms, it’s harder than it sounds.

I went to bed relatively early–9:30, and woke up the next morning at about 6. I went to breakfast in the hotel restaurant, got a rather large meal, and then headed to my room to study more. I wrote more algorithms and redid some I had done the previous night.

Oh, I also wrote down in my notebook (beginning on the plane ride up) questions for Google, as well as answers to questions they could ask me (standard interview fare–projects, favorite project, languages, strengths, passions, getting along with people).

My interview was scheduled for 10 am–I checked out at 9:30 and left with my bag (I had everything in a single bag I could carry–it was very heavy) and sat in a little square for a few minutes. At about 9:50, I went in, took the elevator, and was greeted with:

.

. (ready for it?)

.

The Google

Dr. Seuss land! Yes, that was my first thought. I think the door was green, the reception area was very colorful. The receptionist was very nice and asked me to sign in on a computer, which printed a name badge for me. They had some research papers by Google employees on a wall, so I grabbed a couple (their hard drive failure study, and map/reduce). After a few minutes, my Boston recruiter came out and greeted me, offered me a drink from their free fridge, and took me to a small conference room, furnished, it appears, from Ikea. It was simple, clean, and very nice. There was a white board. I would get to know that whiteboard very well.

My first interviewer came in and we got started. I talked about my projects for a bit, they answered my questions, and then we got to the problem. Each interviewer asked me to solve a single problem (could be some sub-problems involved), and I had to do it on paper or on the board. I wrote C/C++ code. They take note of what you write and ask you further questions, especially if your first solution isn’t optimal.

I tried to take extra care with my code and not let stupid mistakes creep through. I used good variable/function names, made sure my braces matched, and I ran through the algorithm on the board once I had written it.

The first interview was one of the toughest. I was more nervous. I think I made more mistakes–I didn’t see things as quickly as I did later.

I had three interviews before lunch. They then handed me off to someone else who would not be evaluating me, but would just be an escort for lunch. The Google cafeterias in Mountain View are legendary, but the Boston office is far too small to warrant such lavishness. Instead, they have a catered lunch every day. It was wonderful. They also have all the free drinks and candy you could want, available all the time. I spent much of the time asking my escort questions about Google, what he was working on (couldn’t tell me), the area, the office, the commute. We were also joined by the head of the office, who didn’t realize I was an interviewee, and we had a nice conversation as well.

Lunch was an hour, and then I was back in the conference room. I had two more interviews. Then the recruiter came back in at about 3:15 or so and debriefed me–asked me my impressions, how I felt. I reiterated what I had told him on the phone previously, and that morning before we started: that I was trying to take this as easy and nonchalantly as possible, to have fun, and learn, and let it be a good experience. I had a job that I enjoyed, and didn’t NEED this one, but I think I would do well there and enjoy it very much. They came to me, after all.

I think by the end of the day, I was really pulling that off well. Once I got over my nervousness in the first interview, I really did have fun and enjoy it.

General Notes

They didn’t ask me any stupid questions. None of this “what’s your biggest weakness?” garbage. Not even the recruiter asked me anything like that. Nothing silly at all. They also didn’t ask me easy technical questions. They got right into the problems and the code. I had to describe an algorithm for something and write code for it. It was serious, they were all nice–I met people with serious reputations online. I felt like they were respecting me as a fellow programmer–almost. I wasn’t one of them, but they really wanted to see if I could become one of them.

I did receive prompts to get through certain problems, but not overly so. I answered every question they asked. Some I answered better than others, but the ones I didn’t get right away, I had alternate solutions, and I understood where they were going as soon as they started talking about it.

Why I didn’t get the job

Well, companies these days won’t tell you why. I think they fear it opens them up to lawsuits. I think that’s silly. It prevents those of who really do want to learn and improve from knowing what we’re deficient in. Oh well. They told me that they thought I would do well at Google, but that it wasn’t a good fit at the time, and I should apply again in the future. (Of course, I didn’t apply in the first place.)

My suspicions, however, are that I lean too much towards Microsoft technologies. I do a lot of work in .Net. That’s where more and more of my experience is. I do consider myself very good in C++, but I’m doing more and more C# work. I’ve always been a Microsoft Windows developer.

I also am not really interested in web-centric technologies, and I told them so. I’m more interested in client apps on the desktop, and server apps.

Of course, it’s very possible I just didn’t answer the questions to their satisfaction–that I needed more prompting than I should have. Oh well.

It could also be that my GPA wasn’t what they wanted. I goofed off my freshman year of undergraduate work. I really hurt my grades. I came back, though, and got straight A’s for my last few years where I took the hard CS classes. I also got straight A’s in my Master’s program while I was working full time. I don’t think this was the issue, but it’s possible.

Lessons

  1. Having your own web-site is a no-brainer. Do it. Update and maintain it.
  2. Do personal projects. You must be passionate, you must love programming. You must be good at it. Not average. You must aspire to excellence and be working towards that.
  3. Know what you’re talking about it. Don’t show off–just display your knowledge as it applies to what they asked you.
  4. Use an interview with them as a learning opportunity and ensure you have a good experience regardless of the outcome.
  5. Don’t take the interview too seriously. Make sure that not everything rides on the outcome. You must be comfortable, confident. You must try for success in every possible way, but yet be completely prepared to fail–and have that be ok. This is a hard balance to achieve, but I think it can really make you have a healthy outlook and have a good time while still showing your best self.
  6. If you don’t get an offer, realize that even being selected for an on-site interview by Google puts you above the ranks of the average-good programmers. Google gets 1,500 resumes a day. You’re already in the < 1% percentile.
  7. Practice writing code by hand in a notebook. This helped more than I can express. Do stuff that’s hard that you don’t know how to do immediately. Time yourself. Make the problem more challenging. If you can’t stretch yourself, they will and you’ll probably break. They did not ask me to do any of the specific questions I had practiced–but the experience writing out and the THINKING is what helped.
  8. Be able to explain your background (90% technical / 10% personal) in a few words. At some point you’ll be asked.
  9. Have a lot of questions for people. You’re interviewing them too. Make sure they’re good questions. Asking about salary is not a good question before you’ve been made an offer.
  10. I let the interview build my own self-confidence. I have no doubt that I could walk into an interview anywhere else and it would be laughably easy.
  11. Don’t ignore obvious, simple solutions. Sometimes a table lookup is better than an O(n) algorithm.
  12. Bring a good, FUN book for the plane ride back. On the way, I focused on the interview, but on the way home I wanted to do anything but, so I had my current novel (Dickens’ Bleak House–very good book, by the way).

If you do all of those steps, it actually doesn’t really matter if you apply to Google or any other great/famous company–you’ll probably get the job you want for the pay you want anyway. Somebody, sooner or later, will come across you and give you the opportunity.

Great programmers will rarely, if ever, need to look for jobs.

I hope this long, rambling essay is helpful to some. I make no claim that my experience is typical or that I’m being completely objective. In other words, YMMV.

Read part 2 of this article


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at: