Chris O'Meara

Refreshing Change

2011-10-21T12:37:00.000-07:00

Our local Ruby Meetup lost it's meeting place at the last minute this week and we ended up combining with the Sacramento Web Standards Group at the The Urban Hive.

I heard a well-prepared talk from Mark Aplet and Andy Ford on the topic of Responsive Web Design. It definitely fell outside my normal discussion topics -- like Ruby, Rails, TDD, etc. I felt strangely invigorated and refreshed when I left.

That feeling caused me to reflect on the Pragmatic Thinking And Learning book by Andy Hunt I've been reading. He points out that change stirs creativity.

Part of it was the space: Urban Hive oozes creativity.
Part of it was the topic: I have a huge appreciation for beautiful things, especially web apps.
Part of it was the people: front-end developers and designers are just different enough from programmers. They dress differently, speak differently, use different tools, think differently about problems. And yet they do work so very closely related to traditional developers. It upsets something in my brain in a good way.

I should get out more.

Slow Down To Go Fast

2011-10-21T10:10:00.000-07:00

Note to self: when I feel overwhelmed with workload I need to return to the basics. Going fast is a matter first of efficiency. Remove wasted effort.

Under tremendous pressure, there is a very real risk I fixate on the volume of work and, as a result, freeze. How do I resolve the deadlock? Slow down.

Being a knowledge worker that means:

Collect
Plan
Do what I can't delegate

Now, back to work.

Following My Own Advice

2011-01-09T14:24:00.000-08:00

As I've recently transitioned from my consulting life to managing a software-as-a-service (SaaS) team as an employee I find myself working hard to follow my own advice. As a consultant I had the opportunity to observe and advise. The implementation typically fell to my clients.

Now I am my own client, in a way, and the advice I gave in the past still applies.

Two principles come to mind after a week on my new job: 1) leaders drive cultural norms and 2) improvements are best made as small, incremental changes.

Cultural norms reflect the reality of what life looks like on your development team. Would a developer hack a file in production and leave it there? How long does it take to notice a broken build? Is untested code OK? Your team communicates the answers to these questions every day they work. The leader in the team implicitly approves and disapproves of individual behaviors by his/her responses. A capable leader explicitly trains, gives feedback, encourages and makes room for the team members to do the right thing. The leader shapes the cultural norms. I ask myself, "what cultural norms am I driving in my team?"

Balancing the training, feedback, encouragement and overall change is the need to perform all these activities without alienating people. These are people, after all. Rapid, forceful, massive change has it's place but it's disruptive, destructive even, at times. I want gradual, sustainable, incremental change so that I can guide my team towards more effectiveness without alienating my teammates in the process. I ask myself, "what change would help my team gain the most effectiveness and what is the next step toward effecting that change?"

So now I give myself a new principle to apply: integrity is following your own advice.

Teaching Junior To Program

2010-11-02T13:30:00.000-07:00

We homeschool our 9 year-old son and the time has come for Junior to learn to program.

He loves to tinker. A while back I found him with a pile of batteries, several paperclips, duct tape and a light bulb. The system was dubiously connected but any little glow from the bulb resulted in shouting from the kitchen table. "Dad! DAAAAD! My light, it's working!" He makes his own swords for sword play. He builds miniature buildings and invents new costumes for his favorite stuffed animal.

He wants to know what I do all day. Once or twice he's pulled up a chair to watch me work in my home office. He thinks it's curious I spend so much time waiting for tests to run. He knows I "teach" computers, or at least that's how I explain it to him. I think his curiosity will work for him as he learns to program. I also think his love of music and talent for language will help him grasp the idea of a model as a reflection of reality, which is the basis of computer programming.

I set out last weekend to plan for Junior's introduction to programming.

I didn't find what I was initially looking for. I wanted a book or a blog titled "How to Teach Your Curious, Creative, Music-Loving Junior Linguist to Program." What I did find was a series of resources I can string together to accomplish such a thing.

First, I am amazed to learn how approachable microcontrollers have become for the education setting. The BASIC Stamp, produced by Parallax, is a thoroughly respected option when it comes to learning to program an embedded system. They produce a complete hardware and software solution with what appears to be an excellent teaching manual. It looks like tons of fun. You can make your way through the book and then move on to build whatever you can dream up based on modules you can purchase and add on to your initial kit.

BASIC Stamp is not the only option though. The open source hardware project Arduino is another option. This choice requires more initiative on the part of the parent or educator since there is nothing like Parallax's "What Is A Microcontroller?" book. Arduino fascinates me because I find it so approachable. There are tons of resources available for sample projects and kits. Assembling a curriculum will not be difficult.

Second, there are some really smart people working a project called Scratch over at MIT. Scratch looks like a great way to introduce kids to programming using games and stories. It's not hard to imagine how programming, in this context, becomes like a video game and creates a virtuous cycle in which kids want to learn more so they can play more. The development tools don't look anything like the tools I use as a professional, which is probably a good thing. The tools avoid complexities like source code files and eschew text-based syntax for a graphical drag-and-drop assemble-your-program-model.

Despite being so widely used in education, I actually found it difficult to find a curriculum I could use. I found several articles and forum posts by educators talking about using Scratch but they generally had developed their own coursework. I got the impression that I could probably go find a project on the Scratch website and start modifying it to suit our education needs. The ease with which Scratch projects can be shared is brilliant, by the way.

Third, I found some books which aim to teach children to program using a general-purpose programming language like Python, for example. These books seemed less focused on children, actually, and more focused on beginners in general. This approach didn't strike me as particularly compelling. I suppose it is fair to say I'm less focused on causing Junior to learn programming at this stage and more focused on teaching him to enjoy his creativity and explore programming. If he takes to it, there is a place for the more complete approach.

On my wife's advice, I'm keeping it simple and engaging for now. She does, after all, do this for a living. Junior and I will learn microprocessor programming together. We will use an Arduino because it's cheap and I find it fascinating. We will go through the Getting Started With Arduino book together and see what my curious, creative, music-loving junior linguist finds fun and interesting. I'll keep a watch out for what he's good at. At the very least, he will learn what I do all day.

The Pensive Collaborator

2010-02-07T13:34:00.000-08:00

Do you find yourself feeling frustrated when you collaborate with certain people? Do you feel like they respond to your written communication in fits and spurts? Sometimes the conversation flows but other times they act like a communication black hole, killing the exchange in the process.

I think there's a certain kind of collaborator whose primary characteristic is that, when it comes to written communication especially, they think deeply and seriously before responding. These people are pensive and I think I am one.

I find it very difficult to participate in online forums, mailing lists and even, to some extent, email conversations. I'm not overly private but I'm coming to understand I'm pensive. Written communication comes to me after deliberation.

I read a thing and I think, "Oh, I have an opinion about that." I'll explore the opinion enough to give it a mental title, a headline maybe. But then it needs to sit. There's a part of my brain that fleshes out opinions and makes connections while I'm doing, well, pretty much anything else. The anything else could be paid work like consulting or programming. It could be exercise or taking my wife on a date or a hike with my son. I may come back, do a little research to fill in gaps in my understanding, then put the conversation back on the shelf. At some point the processing is done. I have an opinion and am ready to elucidate that opinion. I'm faced with a dilemma. Do I actually engage in the conversation? Is my pensively-formed opinion still relevant?

Face-to-face I don't have the same problem. It makes me wonder why writing is such a different kind of process.

If you come across someone who seems to respond in fits and spurts to your emails or tweets you might ask yourself if they are pensive collaborators.

Ron Evans' Rules For Social Media

2010-02-07T06:40:00.000-08:00

This tweet from Ron Evans (aka @deadprogram on Twitter) of Dead Programmer Society fame forced me to think about my role in the Ruby and XP/Agile communities:

My rules for social media: find something cool=tweet it, learned something cool=blog it, mastered something cool=present it

It makes some sense to me in terms of a progression of sharing. I like it as a checklist to remember to be a fully participating member in my communities.

I'm working on following the rules.

Probing Code Quality

2010-01-31T14:55:00.000-08:00

A friend of mine recently started as the CEO of an exciting new Software as a Service business. He asked me what I thought about helping him evaluate the quality of the software asset he now manages.

Code quality is such a huge topic. It’s a question of fitness for purpose. Your answer varies widely depending on what you need that software asset to do for you. For example, the method you use to assess the quality of a program to scrape Craig’s List is vastly different from the method you use to assess a web application you use to operate your online auction. This friend of mine has something closer to the auction site than the Craig’s List scraper.

Here are 10 questions I suggested he explore with someone technical he trusts:

How stable is the product right now? What are the outstanding functional defects and non-functional rough edges?
How well specified is the application? If we broke a feature tomorrow, how would we know? Are the specifications executable or do we need a person to manually verify new builds?
How complex is the application right now? How long would it take someone generally familiar with the technology to isolate and repair a problem? Unneeded complexity increases the likelihood of future defects and makes it more difficult to find and retain developers.
What third-party dependencies exist? Open source and commercial libraries imply license terms, fees, etc.
How does the application scale? What can you support on the current infrastructure and what’s the incremental cost of selling new subscriptions?
What provisions are in place to deal with disasters? What is the physical server architecture? How does the system handle losing critical components like servers, switches, load balancers, etc?
What does the development environment look like? What does it take to bring new developers into the team and get them productive?
How is the source code managed? How do you reproduce particular configurations of the app for historical or bug-fixing reasons?
What is the build and release process? How do versions of the software promote through different environments from development through testing to production? How do I safely push new releases into the production environment and how do I revert to previous versions if that becomes necessary?
How do you know how the app is performing? Does it notify you when something goes wrong? Are there any monitoring or management services keeping watch?

Startup CTO: Could It Work?

2010-01-31T13:50:00.000-08:00

A CEO friend of mine recently asked my opinion about Tony Karrer's Startup CTO or Developer article.

I think the part time CTO could work. Here's why.

From a development and operations perspective, the common element in successful software businesses seems to be the technical leader. Their primary characteristics are deep technical skills and a hacker mentality (about the word hacker). They tend to have the knack for architecture. They tend to be capable planners when it comes to issues like performance and security. They tend to have the programming background to lead competent people by example and dig in and prove it where necessary. They tend to know where to find good help in terms of employees and consultants. They tend to know the operations side of a software business well enough to be the one overseeing deploys, crafting the infrastructure plans, and monitoring the health of the product. They tend to be plugged in to tech news sources to be aware of trends and understand how those trends could impact the business. They tend to understand the product management side of the product well enough to guide the technology in a complementary way.

I think that's the person you need. Common sense says you'd do your best to hire or otherwise permanently engage that lead developer. If you think that's person you need, the question becomes "what else do you expect a CTO to contribute?"

The answer to that question is contextual, based on what you, as CEO, and your board believe your "Founder Developer Gap" (reference to the Tony Karrer blog entry) to be. Surely there are some business and technology strategy problems you're going to need help with that your lead developer can't help you answer. Assuming you can't or don't want to afford a full-time CTO, that seems like the perfect fit for a consultant and that seems to be where this idea of consultant CTO makes sense.

In thinking about this problem I asked around a fair amount and couldn't find any solid answers to the question "where have you seen someone in the role of CTO for a startup do a great job?" My colleagues and I interact with startups a fair amount because we're consultants. Many of us have done freelance work in the past, often for startups. We each pointed to key technical leaders that drove the development and operations parts of the businesses. A few had the title CTO but they all fit the technical rock star and hacker profile.

The main thought that gives me pause is that of earned authority. It's about leading by example. Depending on how much face time the consulting CTO has with the team, it could be extremely difficult for a consulting CTO to effect change. The consultant's advice would have to be filtered through the leaders in the trenches. Yourself and your lead dev, along with your other key leaders like product and sales managers, would need to listen, internalize and execute the strategy. I doubt a consulting CTO would have the privilege and honor of earning your team's respect directly. That generally comes from running the business together.

The other problem area is that of growth. Assuming your business succeeds and grows you'll need a proper CTO at some point. Your lead dev may or may not make sense to grow into that full-time CTO position. You could have the same problem hiring for other leadership roles too like Director Of Software Development or Master Bottle Washer. It feels like tomorrow's trouble to me but it's something to keep in mind.