Big Company/Small Company

I’ve worked for a variety of corporations at a variety of points in my career. I’ve encountered people who claim large companies are soulless mind-sucking entities, and small startups are the way to go. I’ve also encountered people who claim small startups are underpaid stressful environments, and the security and camaraderie of a large company is the way to go.

Both suck.

Well, let me qualify that. In both environments you have to deal with people. And people can be bureaucratic, officious, mean-spirited and obnoxious, as well as obtuse, bull-headed, and just plain mean–regardless of the environment in which you work.

And people can also be gracious, kind, polite, helpful, intelligent, and otherwise great to work with–again, regardless of the environment in which you work.

I’ve noticed two differences between a small company and a large company. Small companies mean more risk taking–but have the potential of a massive upside. On the other hand, there is nothing inherit in a small company being “small”–meaning agile, non-bureaucratic, or capable of quickly recognizing and moving on decisions. All it takes is an idiot who is willing to do stupid things to break one’s day.

One could argue that idiots are more rife in large corporations–after all, the the other difference between a small company and a large company is that a large company provides security, or rather, large companies have a greater vested interest in keeping people who understand how things work at a large company, while small companies have a vested interest in getting rid of bad people.

Or rather, a small company may think it has a vested interest in getting rid of bad people–but often small companies lack the experience (or have people at the top) who are unable to recognize their vested interest. We may hear about the successful small companies that go on and make millions for their founders–but how many do we never hear from which fail because of bad decisions or bad execution, caused by bad people who lingered on?

(I’m not speaking of any company in particular, by the way–I’ve worked for several very large companies and very small startups. And it’s always the same.)

In both environments, however, there are really cool projects and really crappy projects. Small companies tend to generate excitement: “hey! we’re on the cutting edge!!!”–but crappy projects are crappy projects. Some large companies like Google have also managed to capture that excitement–but what Google doesn’t tell you is that they’re like the military: unless you are extremely exceptional, you’re going to be fodder for the Google Advertising Serving System. Sure, Google may lure you in with “Go” and “GWT” and cutting edge algorithm research–but chances are you’re going to be working on how to optimize advertising keywords and making billing systems more scalable.

Okay, so I’m working on an advertising system. I’m working on Lead Generation–which is about as exciting from the outside as watching paint dry and grass grow. But there are a few cool things going on here: (1) we’re building a system from the ground up. And (2) we have a chance to make a real difference within the organization through the use of excellent customer-oriented design. What I want (and what I intend to fight for) is Apple-like design-centric design. Sure, it’s an ad system, but it doesn’t mean it has to be a poorly designed ad system.

Live in the Glendale/Burbank/Pasadena area and want to play with GWT? Got Java ski11z? Want to make a difference by providing an ad system that your corner drug store owner or restaurant owner can actually use? E-mail me at my AT&T Interactive e-mail address.

The View from AT&T Interactive.

Pictures from the new job.

I’m actually quite happy right now: sensible people who have solid experience putting together an advertising system that is well understood, with plenty of time to do it in. And while it won’t have the same “cachet” as working for a Google, the biggest win of working for AT&T Interactive is the ability to challenge Google by connecting customers with local businesses and making it as easy as possible for advertisers to get the word out.

I have always strongly believed if you want to conquer the world, make difficult things easy. That’s why the iPhone is taking over the world: Apple no more invented smart mobile phones as they did the MP3 player. But Apple made it easy, and when you realize the millions of cumulative hours spent in frustration by users who wanted something cool and got hacker crap, it’s easy to understand why people were willing to pay hundreds of dollars on an Apple iPhone when they weren’t willing to spend $50 on a Windows Mobile device.

And that’s my goal at AT&T Interactive: make it as easy as humanly possible for advertisers to reach customers. A large part of this involves designing the system so that it makes sense, and it gives people the power to run the ads they want while giving the restaurant owner, the local carpet cleaner and the clothing store owner the easiest tools possible.

You shouldn’t have to be a gear-head geek to use a cell phone, and you shouldn’t have to be a graduate of MIT (or as bright as a Googler) to place local ads.

Why good functional design now will save you a mint later.

Via BoingBoing: Gadget problems divide the sexes

The service found that 64% of its male callers and 24% of its female callers had not read the instruction manual before ringing up.

12% of male and 7% of female customers simply needed to plug in or turn on their appliance.

This is why good design–site design, software design, gadget design–is essential: because 45% of your users won’t read the manual before calling your customer support line.

Whether Mobile.

So the decision to accept a new job at AT&T Interactive as an Architect of Lead Generation means I’m moving away from mobile after three years of doing mobile development or mobile-related development. It doesn’t mean I’m giving up writing software for the iPhone or for Android or Windows Mobile: I have an idea I’m tinkering with in my spare time.

But it does mean I won’t be doing it professionally.

The decision to move away from Mobile development when it is glowing red hot is a deliberate one. I believe mobile development is currently a bubble: I do not believe–with perhaps some unforeseen exception–that some mobile startup will ever grow to become the next Google, Microsoft or Amazon. At best I believe you can make a nice living at it–but you’ll never reach a billion dollar market-cap, unless we have a replay of the Dot.Com bubble of the late 90’s.

The rush into Mobile has been driven by the observation that the iPhone has finally created an environment that is relatively “open” (in the sense that the development tools are free and not the thousands of dollars Microsoft and Nokia used to charge–buying a basic Mac Mini capable of running Xcode is still cheaper than Visual Studio Professional for Windows Mobile.) and shipping an application is relatively “easy” (in the sense that it only costs $99 for a year to obtain a hardware signing key, unlike Microsoft and Nokia who used to charge more). It also has created a mobile computing environment that is powerful enough to run sizable mobile applications, with an always-on Internet connection which allows creating internet-enabled mobile applications a no-brainer. Say what you will about Android and the improvements for Windows Mobile 6.5 and Nokia–but Apple showed the way.

And in the process Apple has made a ton of money.

The believe is that by extension there is a ton of money to be made in mobile: if Apple made a lot of money, so can other software developers. But what they don’t realize is that Apple is making money hand over fist by creating an extremely well-designed product (that, at the time, was a revolution in design) that disrupted the traditional relationship between MNOs (Mobile Network Operators) and headset manufacturer. Never before has a headset manufacturer demanded as much control as Apple has–Apple even went so far as to control the pricing structure, options and the initial sign-up relationship with AT&T’s customers.

Riding Apple’s coattails may make you rich–but it probably won’t. And thinking that Apple is succeeding because they just happened to be the right company in the right place at the right time denies Apple’s contributions to the state of the art: nothing prevented Nokia or Microsoft or Sony or Motorola from doing what Apple did, starting the revolution without Apple.

Which means the analysts claiming the Mobile Revolution is finally here–and Apple just happened by coincidence to stumble, like some drunken idiot, onto the center stage just as the elevator started to rise–those analysts are complete fucking idiots. It’s not a Mobile Revolution–though it is a disruption in Mobile. No, it’s a consumer design revolution. Other companies still haven’t figured that out.

Further, and more importantly, I believe development in mobile is–career wise–a dead end. Basically, any mobile company doing repeat and sustained business will take one of two shapes: a company which repeatedly puts out new products (a game company), or a company providing mobile-based information. The former will probably consist of a handful of two- or three-man teams. The latter, at best, will consist of a two to three person client team and a two to three dozen server team.

The smallness of the teams comes from the reality that there is just so much code that you can put on a mobile device. The mobile software I worked on for Geodelic, for example, was perhaps 15,000 lines total–the server side, on the other hand, winds up being megabytes and megabytes of stuff in the source control worked on by a dozen or so great engineers. And ours was a “fat” client: I suspect programs like Where or the MasterCard Priceless Picks clients weigh in at under 8,000 lines total. Even something relatively complicated as the YPmobile app can’t weigh in at more than 12,000 to 15,000 lines.

Mobile information companies like Where are like iceburgs: the 10% that is visible is kept afloat by the 90% you don’t see. Companies as ambitious as Geodelic–which are seeking to integrate all sorts of stuff into their data stream–are even more so: I suspect once Geodelic has built out the system they are seeking to build, by line count the Geodelic Mobile Client will probably be less than 0.25% of the total lines of code that comprise the overall system.

Such companies are extremely ambitious, and perhaps they may grow–not to Google size, but at least to a respectable middle-sized company. But that means that while the server team may serve to occupy two or three floors of a major office complex, the client side of the company will still comfortably fit into a small 8′ by 10′ corner office in that complex.

I love doing mobile work. I intend to keep doing mobile work in my spare time. But my ambitions are greater than being the lead guy of a three person team when I’m in my 50’s. And I just don’t see that happening in mobile.

A change of scenery.

I was just offered the position “Architect: Lead Generation” at AT&T Interactive.

Changing jobs is hard. Really, when you change jobs, you’re taking a real risk: can you do the work you’re being hired for? Can you come up to speed fast enough and understand the problem set well enough to do the work in a timely fashion? Can you adapt to the new corporate culture–or, if you’re high enough up in the totem pole, create a micro-culture around you that you can live with? With larger companies–like a Symantec, a Sony or a Yahoo!, can you navigate and understand the corporate bureaucracy? And–worse of all–is the project you’re being placed on one that is favored by upper management, or are you being set up to fail because of an internal bureaucratic struggle at a level beyond what you can influence?

With small companies, of course, there are different problems: do the people there have a sufficient skill-set to execute? Can you grow the staff fast enough to satisfy the needs of sales and marketing? Are your initial design assumptions correct or did you just build something that is five degrees off from what the market needed? And of course you still have dysfunction, though often the dysfunction looks different it comes from the same source: people are imperfect, and any organization will inherently have internal competition between its organization members as people have the need (due to greed or ego) to assert themselves.

But the change is always difficult: vacation pay is paid out and you have no accumulated vacation at the new job–meaning that two week vacation you wanted to take is now a year away. There is plenty of time spent navigating the new environment–oh, and the constant “well, of course everyone knows” stuff which bites you in the ass.

For me the decision to change jobs has always been predicated upon a personal evaluation: is the potential reward of a new job greater than the lost opportunity costs of the current job and the risks of a transition? My transition from Symantec to Yahoo! was driven by two factors: a very long commute, and not working on a project that interested me made the opportunity costs of walking away from Symantec relatively low. My departure from Yahoo! was driven by a firm belief in a dysfunctional management structure which (I believed) set up our project for failure–a dysfunction that appeared to me to come from the executive suite. (From what I’ve seen with the recent quarterly results, it appears that dysfunction may be over. But once burnt, twice shy.)

And for me, as someone who appears to be perpetually pegged as a sole contributor, the ability to move into an architectural role at a large company, where I would have managerial and design responsibilities greatly advances my own career path–that’s a big deal. That’s a big upside.

Yes, there is always a lost opportunity cost: leaving Geodelic means I’m giving up working on a product I know like the back of my hand, where all of the major problems have been solved, and trading it for The Great Unknown. I’m also walking away from a potentially extremely lucrative equity stake.

But in the end, I believe moving to AT&T Interactive will put my career farther forward in the direction I want to go–a leadership position–than if I stayed at Geodelic. I’ll have the opportunity to provide significant influence to the front-end interfaces people will use when they interact with our product, and I’ll have the opportunity to build a team and establish a culture which promotes design excellence–which, I believe, is the “next big thing” in the tech industry.

Annoyed.

On Android, it appears android.graphics.Region (which is used internally for clipping against a Path) is not anti-aliased. This means if you set a clipping path that is not rectangular, such as a rounded rectangle, then the interior clipping path will have jaggies.

My workaround for my rounded rectangle clipping with a border is to draw the border after drawing the interior, and allowing the stroke to be wide enough to cover the jaggies. But IMHO it’s a kludge.

Minor point of departure.

If you’re a developer, you probably have already read it, or read about it: The Duct Tape Programmer. There are some really good points about this article–but it’s clear that the article itself is written by someone who is not a duct tape programmer.

The differentiation between an Architecture Astronaut and a duct tape programmer is pragmatism and simplicity:

You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the Architecture Astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.

Architecture Astronauts proclaim with absolute certainty whatever it is they are promoting. Duct tape programmers say “shut the hell up and get this out the door.” Your toolkit is just that: a toolkit, and there is no point in tossing that toolkit out the door for new tools simply because it is the new hotness.

So how does Joel Spolsky characterizes Duct Tape Programmer thinking? By being an Architecture Astronaut:

Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

“Stop it, just stop.”

Each of these have their place, if your first desire is to ship. Me, if you treat C++ as C with classes, avoiding templates (unless it’s a STL object, ’cause using std::vector is easier than rolling your own), and for the most part avoiding exceptions (because the rules for exceptions can get really convoluted), then you should be fine. C++ is a tool, like Java, like C, like Objective-C: C++ has more potential pitfalls, but just ignore them. Multiple inheritance also has it’s place: it’s what you do when you accidentally code your class tree into a circle and don’t have time to renormalize things into a well-defined class hierarchy. Multi-threading only is useful when dealing with networking or when you put the thread handling into a thread queue and can just create a well-defined process and toss it in–and if you want to ship on Windows, you have to deal with COM.

And if we’re going to complain about CORBA, can we also complain about SOAP–which is not simple, despite the name? And can we complain about all the additional crap (like introspection) being tossed into the base XML-RPC specification?

The two overriding rules are “just ship the damned thing” and “sometimes life is messy.” Towards the first “just ship the damned thing”, it means don’t be afraid to use yesterday’s well-defined tools rather than today’s cutting edge experimental crap. It means avoiding the well-known pitfalls in the tools: if you treat C++ as C with objects, it will be far better than using C and trying to build your own class hierarchy processing. It means not rebuilding what someone else has done for you for free: why use C with objects when you have C++? Why build your own Complex number type or dynamic array processing or hash map, when there is std::complex and std::vector and java.lang.HashMap? And it means sometimes you’ll code something because it’s what will ship, rather than architecting something that is beautiful–which means sometimes you’ll find yourself creating a class which multiply-inherits or a Java class with half the methods written as one-line delegates. Because it’s ugly–but it will ship. And do you have time to figure out how to reorganize your class hierarchy into a strict tree representation?

Sometimes it also means knowing where to draw the line when using a toolset. Me, I like C++ but hate templates with a passion and think exceptions are good if used in a limited way. I like Java because it allows you to write a lot of code quickly, but hate Java because it has allowed lots of people to write lots of code quickly–and in the hands of an Architecture Astronaut it’s allowed them to create all sorts of abominations that showcase their theoretical bullshit. (cf: Spring or Hibernate, which has struggled to make a simple problem impossible to solve. Cross cutting? Puhleeeease…) The last time I wrote a Java server, I wrote code directly to the Servlet layer, with a simple bit of parser code to parse XMLRPC. Took me an afternoon to get up and running against an iPhone client.

It certainly also means waiting to jump on the next tool bandwagon once it stops being a theoretical playground for bored Architecture Astronaut wannabe weenies. Which is why I’m not on the Ruby on Rails bandwagon or the Code in the Cloud concept. I like tools that are well-defined which have well-defined and mature development tools: one reason why it’s easy to write code in Java is because there are many solid IDEs which help you write code. (Eclipse, Netbeans, IntelliJ).

Just ship the damned thing already, okay? Remember: shipping is a feature far more important than any other feature in your product.

Someone read my mind!

Wouldn’t it be great to have a drawing program on the Macintosh which, after you’ve composed the artwork, can export the drawing commands for Cocoa’s Quartz or the iPhone, so you can cut and paste code to draw the same thing in your program?

I thought that would be so cool. And now it turns out someone beat me to it: Opacity.

Now if only there were exporters for Java AWT, Android’s UI toolkit, and Microsoft Windows…