Baveo allows users to post photos, videos, and text updates to a blog devoted entirely to the newest members of the family. The site is well designed for parents and family on the go. Parents can post directly to their Baveo blog via their site or their phones, and friends and family can stay updated via email or text messages.

I recently had the chance to chat with Ari Greenberg, Baveo’s CEO and founder. Ari helped break down where the idea for Baveo came from, how the team came to be, what they’re up to, and a few other thoughts about being an early entrepreneur.

After witnessing a childhood friend and his wife blog about the birth of their first child, Ari’s idea for Baveo was born. Ari saw the chance to make a wonderful and important experience even better. Expecting parents deserved a better and more integrated blogging experience.

Previously at Magnify.net, Ari spent his free time exploring the project further. He had always known he wanted to start his company, but he lacked an idea worth pursuing.

Baveo quickly became that idea, and when he realized it, Ari wasted no time building a team of three. Everyone works for equity, and Ari wouldn’t have it any other way. It’s how he knew the team believed in the idea and wanted to see it succeed. It also ensured the team would be honest with him and tell him when things weren’t going right. Both are equally important.

The site is currently invite-only so the team is working towards building out new features and publicizing the site. There’s a large community of mom and dad bloggers out there for them to tap into, and they’re exploring ways for users to better capture and share baby memories.

No matter what they think now, though, the team is focused on letting their users decide where Baveo goes next. “Everything needs to be about the user,” Ari says, “Users will tell you what they want if you listen.”

For all of you expecting parents out there, sign up for a Baveo invite now. Let your friends know what’s going on with your little cherub and let Baveo know what you think of their service. They’re listening.

The book is written based on Brooks’ experiences with large project teams for IBM working on systems that pre-date this author’s birth.  While the lessons are written for software teams, they’re not necessarily about software. In fact, most of this book is focused on people and project management.

The Mythical Man-Month explains why “Adding manpower to a late software project makes it later.” It describes project tracking and the effect of small slips in your project schedule, and the importance of documentation. You can just as easily see this on the bookshelf of an M.B.A. as an engineer.

Part of what’s so interesting about this book is that it helps you gain perspective on the history of software and where the present fits in. The industry has come pretty far since 1975, but it’s still only decades old. The essential lessons of the Mythical Man-Month will continue to become more like fundamentals and less like exact truths.

In fact, I think part of that has already happened. As someone with only a few years of software experience, I had heard a lot of the Mythical Man-Month’s lessons before. I just didn’t know their origin. I think it’s reached the status where the lessons are more important than the work. Some day it will be whittled down to what fits into a chapter of a text book, if it hasn’t already.  Students today don’t read Einstein’s paper on relativity, but they’ll certainly be taught it.

My final thought on the Mythical Man-Month is that, sure, it reads a bit outdated. How could it not? You should understand what’s in this book, regardless. At this point though, you can probably get most of The Mythical Man-Month’s lessons from the Wikipedia page. Check out the whole book for a little bit of history.

Other reviews:

• Amazon Reviews
• Slashdot Review
• Tal Cohen’s Book Review
• Scott Rosenberg’s Review
• Ed Willis’ Review on On Lamp

On every blog and developer checklist, however, I kept hearing about this book, the Pragmatic Progammer by Hunt and Thomas. Recently, I was due for a new technical book and decided I could use an essential guide in the fundamentals. Pragmatic Progammer was the perfect choice.

I started reading this book for two reasons. First, for the developer side of my sweeper practice, I wanted to be efficient with my time, ensuring I would do things the right way, the first time. Second, I foresee a career of working with developers, and it makes sense for me to know what makes a good developer, how developers think.

While reading Pragmatic Programmer, I also realized that many of the lessons were applicable to any job, craft, or career. Use the best tools, be efficient with your time, improve as you go, plan, test, be thorough, etc. These lessons are ubiquitous.

Throughout the book, the authors have sprinkled just these types of career-neutral tips that perfectly summarize the book’s concepts. Rather than explain them all to you, I thought best to try something different and use this post to give you all of Pragmatic Progammer’s 70 tips — for progammers and people, alike:

1. Care About Your Craft
2. Think! About Your Work
3. Provide Options, Don’t Make Lame Excuses
4. Don’t Live with Broken Windows
5. Be a Catalyst for Change
6. Remember the Big Picture
7. Make Quality a Requirements Issue
8. Invest Regularly in Your Knowledge Portfolio
9. Critically Analyze What You Read and Hear
10. It’s Both What You Say and the Way You Say It
11. DRY – Don’t Repeat Yourself
12. Make It Easy to Reuse
13. Eliminate Effects Between Unrelated Things
14. There Are No Final Decisions
15. Use Tracer Bullets to Find the Target
16. Prototype to Learn
17. Program Close to the Problem Domain
18. Estimate to Avoid Surprises
19. Iterate the Schedule with the Code
20. Keep Knowledge in Plain Text
21. Use the Power of Command Shells
22. Use a Single Editor Well
23. Always Use Source Code Control
24. Fix the Problem, Not the Blame
25. Don’t Panic When Debugging
26. “select” Isn’t Broken
27. Don’t Assume It – Prove It
28. Learn a Text Manipulation Language
29. Write Code That Writes Code
30. You Can’t Write Perfect Software
31. Design with Contracts
32. Crash Early
33. Use Assertions to Prevent the Impossible
34. Use Exceptions for the Exception Problems
35. Finish What You Start
36. Minimize Coupling Between Modules
37. Configure, Don’t Integrate
38. Put Abstractions in Cod, Details in Metadata
39. Analyze Workflow to Improve Concurrency
40. Design Using Services
41. Always Design for Concurrency
42. Separate Views from Models
43. Use Blackboards to Coordinate Workflow
44. Don’t Program by Coincidence
45. Estimate the Order of Your Algorithms
46. Test Your Estimates
47. Refactor Early, Refactor Often
48. Design to Test
49. Test Your Software, or Your Users Will
50. Don’t Use Wizard Code You Don’t Understand
51. Don’t Gather Requirements – Dig for Them
52. Work with a User to Think Like a User
53. Abstractions Live Longer than Details
54. Use a Project Glossary
55. Don’t Think Outside the Box — Find the Box
56. Start When You’re Ready
57. Some Things Are Better Done than Described
58. Don’t Be a Slave to Formal Methods
59. Costly Tools Don’t Produce Better Designs
60. Organize Teams Around Functionality
61. Don’t Use Manual Procedures
62. Test Early. Test Often. Test Automatically.
63. Coding Ain’t Done ‘Til All the Test Run
64. Use Saboteurs to Test Your Testing
65. Test State Coverage, Not Code Coverage
66. Find Bugs Once
67. English is Just a Programming Language
68. Build Documentation In, Don’t Bolt It On
69. Gently Exceed Your Users’ Expectations
70. Sign Your Work

Serial entrepreneurs master the process of creating a business. At a recent NY tech meetup, Kevin Ryan, CEO of AlleyCorp, explained how he built his businesses. He spends several months working with a small team to build the business, then focuses on recruiting and moves quickly to the company board. It doesn’t matter what type of business he’s building. He builds to his process, and by the looks of AlleyCorp’s portfolio, it seems to be working

The Art of the Start by Guy Kawasaki explains exactly the same sort of process. Just check out the book’s major sections:

• Causation
• Articulation
• Activation
• Proliferation
• Obligation

Figure out what you want to do, how to make meaning. Next, refine your message. Start your business. Grow your business. (As for Obligation, it’s just a great life lesson about how to play nice on your way to the top. It’s a little ‘be the change you hope to see in the world’-ish.)

In 200 or so pages, he explains his process for building a company. Rather than a book though, this reads more like a checklist. Each part of his entrepreneurial process is condensed and mapped out, and I wouldn’t be surprised to find a private checklist similar to Art of the Start stashed away at Alltop headquarters.

This book is great for helping you refine your idea. At the beginning of your entrereneurial journey, the sky’s the limit. You could become anything. Before you can ever get started though, you have to explain your brilliant idea to someone else. Most often, this person’s attention span is the length of a powerpoint slide or two. Art of the Start helps you do this. It teaches you how to build constraints into your process to elicit refinement and creativity.

To show you a little bit of what I mean, I’ve pulled out a few quotes / notes from the book:

• Who has money? How do we get it?
• Describe your business model in 10 words. Pitches should explain your concept in the first minute
• Prove concept, complete design, finish prototype, raise capital, ship testable, break even.
• Clean up your problems or disclose your problems, but never hide your problems.
• The Ideal Board consists of the customer, the geek, a calming influence with experience, a Jerry Maguire with connections, and a tight-ass who pushes for totally legal and ethical practices.
• Find lawyers who are problem solvers, not ones who tell you what you can’t do.
• Create contagion: cool is beautiful, contagious, disruptive
• Product should be easy to understand ‘out of the box’, but have legs. The more you use it, the more you discover
• Create buzz then get ink.
• Make friends with the lower ranks of reporters.
• Allow users to test drive the service, then decide whether to stay or go.

Flipping through the pages of Art of the Start reinforces Kawasaki’s emphasis on process. It reads like a guide or text book full of tables, exercises, images, and well organized paragraphs. Thankfully, the book reads more like a blog than a text book and costs a lot less.

If you take anything away from The Art of the Start, appreciate the devotion to process. Kawasaki has numbered out the steps to starting and growing your business. If you want to learn a repeatable entrepreneurial process, this is a great place for an early entrepreneur to start.

Several months ago I asked my friend Laks to recommend a good book that would really help me better understand how software should be done. For the past two years, I’ve worked in two completely different environments and seen two completely different ways of creating a web application. Unfortunately, I’ve never really felt like I’d learned to do things the right way.

I first tried reading the book online, but I didn’t appreciate the book in the same way when I had to follow a link somewhere, get up from my computer, sit down and find my place if I hadn’t left the page open from the night before. I knew I enjoyed what I was reading, but it was hard to keep coming back so I broke down and bought the book version for $25.

Aside from The Elements of Style, I don’t think there’s a smaller, more valuable book out there. I read the book on my way back from this year’s New Orleans Jazz Fest. On what should have been a let down flight, I found myself riveted by all 187 pages of this thing. A day after Jazz Fest and 2 hours into my flight I had the chills.

Getting real isn’t the type of book that’s going to tell you what to do with every little detail. It tells you how to focus on a tightly focused framework that will guide you to how you should handle every little detail. Just check out the chapter titles:

• Introduction
• The Starting Line
• Stay Lean
• Priorities
• Feature Selection
• Process
• The Organization
• Staffing
• Interface Design
• Code
• Words
• Pricing and Signup
• Promotion
• Support
• Post-Launch
• Conclusion

Talk about brevity. This book hits you over the head with its succinctness. Try digging through another book about software and see if you can find as much covered in as few words as 37signals has done with Getting Real.

One of the tell tale ways I know I’ve found a good book is by checking to see how many pages I’ve dog ear’d. I’d say about 15% of this book meets this description. There’s all kinds of gems in here, everything from hiring:

“Find someone who’s enthusiastic… Someone who’s excited to build what you’re building. Someone who hates the same things you hate. Someone who’s thrilled to climb aboard your train.”

To making opinionated software:

“Some people argue software should be agnostic… We think that’s bullshit. The best software has a vision. The best software takes sides.”

To how to approach any type of problem:

“Are you facing an issue that’s too big to wrap your mind around? Break it down. Keep dividing problems into smaller and smaller pieces until you’re able to digest them.”

And on and on. Or not so “on and on”? The book’s only 187 pages!

Finally, if you’re not ready to plunk down $25 for your own copy, check out this David Heinemeir Hansson speech. Let one of the authors push you over the hill:

(Isn’t Omnisio’s video / powerpoint slick? I have to think this will become more popular.)

I don’t think I’ll ever stumble upon the best way to create software, but I think this book is certainly close.

It’s inconceivable in today’s world that you could operate any business but a laundry or a bodega without the means of a website. Yet, there are a surprising amount of people who have to design a website with no absolutely no idea as to how they are built.

Remember those organic farmers? They don’t want or need to know know what your algorithm does, how you hacked IE6, or how many coffees it took to pull it off at 4:30am. What they should know, or need to know, is why you put that option there, why that button takes you to that screen, and well, possibly a little bit about that algorithm.

Just as we’ve taught students to read and write in order to communicate for themselves in the ink and paper world, today’s world requires that everyone understands the way a website is created — at least the front end.

Designing Web Navigation by James Kalbach is the perfect book for this group. It’s a great book for anyone working with websites with tons of great references, but those of you who aren’t looking to create the next Google will find the book especially helpful.

This book introduces you to the way you a user orients themselves and navigates through your site. It focuses on the tools that will allow you to create a site that caters to and supports your users. It touches on the way the site is built, but doesn’t get bogged down in the unnecessary details.

For a preview, check out the table of contents:

Part 1: Foundations of Web Navigation

• Introducing Web Navigation
• Understanding Navigation
• Mechanisms of Navigation
• Types of Navigation
• Labeling Navigation

Part II: A framework for Navigation Design

• Evaluation
• Analysis
• Architecture
• Layout
• Presentation

Part III: Navigation in Special Contexts

• Navigation and Search
• Navigation and Social Tagging Systems
• Navigation and Rich Web Application

The book takes the website beginner through the conception of the site, structure, and how to flesh out the details that will frame the way the user interacts with the site.

The final chapter devoted to tagging seemed a bit like an after thought, but that may be due to my prejudice against tagging. It leads to a quicker way to visually summarize a lot of content, but I’ve never found tagging to be particularly useful for navigation.

I think books like Designing Web Navigation can help bridge the divide between developers and subject matter experts. There’s an education that needs to happen on both levels and I think this book is a great place to start meeting each other in the middle.

Even better for you non developers, by learning how to think about websites, you’ll have something to talk about when those Google guys want to hire you.

Part of blogging’s charm is the fact that you’re in complete control of how and what you write. There’s no Ms. Muhilly or Mr. Munro to watch over your writing. You can use all the comma splices, run on sentences, and awkward phrases that you choose.

But, do you really want to? Or better yet, do your readers really want to read your comma splices, run on sentences, and awkward phrases? Do you want them reading your blog posts and scratching their heads trying to figure out what the hell you’re trying to say? I didn’t think so.

Bloggers, you are writers. Improve your writing.

I don’t consider myself a strong or even good writer. I hated English class in high school and grudgingly attended my required writing and literature classes as an engineer at Columbia. Before beginning this blog, though, I made sure to brush up on the fundamentals. (Ms. Muhilly can attest to my lackluster performance in English class. I still remember the look on her face when she found out I got into Columbia.)

The Elements of Style by Strunk and White is the perfect writing book for the blogger / entrepreneur who wants to improve their writing. It’s short. It’s concise (which is something this blog strives, sometimes unsuccessfully, to be), and it’s relatively cheap.

For those of you who are familiar with this useful little book, yes, I know. It’s more of a reference guide than a book. For early entrepreneurs though, ignore that fact and read it like a book. It’s barely 100 pages and there are all kinds of useful tidbits that you might miss if you simply treat it as a reference. Once you’ve spent an hour or two reading Elements of Style, then you can save it on your bookshelf as the reference guide it was meant to be.

The Elements of Style as we know it today took decades to be written. Prof. William Strunk Jr. wrote the original Elements of Style as a gift to his students struggling with the English language’s vast set of rules and principles. One of those students, E. B. White, author of Charlotte’s Web and various other titles, later revisited his professor’s gift to the language and was so enamored with it that he added and updated his professor’s little book. Unfortunately, Strunk never lived to see the current version, but his lessons in writing clarity have since reached millions.

I’m glad White helped make this book what it is today and only wish I had found it sooner. In a previous life where I worked for an Indian financial and software firm, one of my duties was editing research reports written by the firm’s financial analyst group. As a native English speaker, it was easy for me to spot and revise awkward phrases, but I struggled to give feedback to the authors.

How exactly does one describe the difference between which and that? Well, “That is the defining, or restrictive, pronoun, which the nondefining, or nonrestrictive… That tells which one… Which adds a fact about the [object] in question.” The Elements of Style is filled with these 3-4 sentence rules of thumb that will help make your writing clearer and more succinct.

There are numerous lessons like the which versus that section that are perfectly suited for quick reference. Early entrepreneurs should always be improving their writing and useful reference guides like this are just one of the many tools that can help. This sort of book isn’t about changing your writing, it’s about streamlining it. Why say “he is a man who…” when you can say “he is…”?

Ultimately you have to “write in a way that comes easily and naturally to you, using words and phrases that come readily to hand. But do not assume that because you have acted naturally your product is without flaw.”

Note: I ‘ate my own dog food’ on this one.  The Elements of Style helped me with a few awkward phrases in this post, and had I taken the time, I’m sure I could have used it further.

Books, on the other hand, have been used to teach us for centuries. They were made to sequentially build knowledge from page 1 to page n. Early entrepreneurs struggling to get going will serve themselves well to read books (and blogs too). In addition to all of the online resources I’ll refer to in this blog, I’ll also periodically post book reviews and recommendations. Here’s my first.

Edward Tufte’s Envisioning Information is a book almost everyone should read — that is, anyone who has ever looked at a graph, map, poster, schedule, manual, musical notation, monument, software application, or color palette, which is roughly ‘almost everyone’. It’s obviously not at all specific to web design but instead breaks down basic principles for understanding or creating any graphic information display

“It’s the way they draw these wretched tables.”

The book boils down to two themes. Without words, what are you trying to say and how should, or can, you say it? That statement’s a bit of a blunted version of his book, but if one remembers anything about this book those two themes should be it.

Tufte’s book is obviously a bit more detailed so to give you an idea of what’s inside, here’s a brief summary of the chapters:

• Escaping Flatland – Escaping Flatland is the central theme of the book. We live in a 3D world and (so far) we don’t have 3D information displays. What are we trying to display and how can we do it in 2D?
• Micro/Macro Readings – 2D displays are not only limited by a dimension, they’re also limited by area. How do you communicate a lot of information, with a little space, while still making details easy to find?
• Layering and Separation – One of my favorite sections, layering and separation focuses on identifying the different pieces of information that need to be displayed and how they can be distinguished from one another.
• Small Multiples – Graphical displays have to communicate range in time, blood flow, last week’s stock price. Comparing change is what makes data useful at all.
• Color and Information – Our eyes can only deal with so much. Using color appropriately helps save them from working too hard.
• Narratives of Space and Time – Combining space and time brings us back to the beginning. How do we recreate our world?

As hinted earlier, Tufte uses a variety of examples to communicate these themes. His design examples range in time from the Middles Ages to the software age. To illustrate the way we communicate time intervals, he uses a mix of planetary orbit paths, train schedules, and dance steps. Often, to emphasize his examples, he uses images with text in a variety of foreign languages where few, if any, of his readers will be able to understand them all. It requires you to read past the text and focus on his lessons.

Tufte’s book is just plain fun to read. His book makes well on its promise to employ good design. It’s constructed on a combination of well deployed white space, gray scale and color images, succinct explanations and useful side notes.

I’ll take away from this book an appreciation for information design in ways that are far more reaching than web design. It’s helped me better improve the way I read, understand, and am able to create any graphical display.

For anyone that’s looking for a place to start with any design, Envisioning Information by Edward Tufte is a great place to choose as your page 1. And, after that, he has a few other books..