Look like an expert to the public

"The fastest way to look like an expert in something is to publicly accept the blame for why it doesn't work."

- Philosopher Amin

Amin gone Android

I have partnered up with a friend from CMU. We are writing 5 brand new Android Mobile Apps and competing for VC attention.

We could use extra bandwidth on a volunteer basis from C# or Java developers, awesome graphics artists and mobile app advocates. Contact me if you're interested. Release for all five apps is in about 3 months.

Thoughts on hopeless searches

"When you're drunk, boring dates look attractive. When you're bored, recruiters look attractive. When you recruit... don't be looking for drunks!"

- Philosopher Amin

Thoughts on learning

"Your parents controlled your feature selection during your supervised learning to create a learning model that steers your happiness and now you desperately need to do a periodic stepwise regression."

- Philosopher Amin

Gods are not disposable

I haven't written for a while. However, for the past few months I've come across one of my pet peeves often enough that I had to write about it for therapeutic reasons.

You know what a God class is? In an Object Oriented Programming language, a God class is a single class responsible for absolutely everything.

Developers who create God classes typically come from a purely functional programming background and usually do not think about handling object responsibility in a modularized way. They end up writing one class that, say, gets everything from the database, does a million different complex things with it in ways that nobody can follow through reading, and then magically outputs the results. The code is absolutely not readable. The most difficult aspect of improving a software team with this problem is that when you initially provide the developer feedback about the issue, they take religious pride in how elegantly monolithic and "simple" their conglomerate artifact is.

In a past project I've literally spent 2-3 months of my life refactoring code that a so-called "software architect" had written. I don't enjoy rework, but it was a critical piece of code that every developer had to deal with, so it had to be readable. Despite the code being at the heart of the company's technology, its lack of modularization prevented any kind of unit testing whatsoever. The actual and expected pieces of data compared in testing after re-factorization were as large as the entire database, because no smaller module from before this process could be picked to be tested. The team velocity, in my opinion, was not nearly where it should have been - and the God-Object anti-pattern was one of the biggest contributors.

The followers of God classes argue that it's faster to prototype that way until you're profitable. The sad thing is that this assumption is incorrect. In fact, if you were to compare a God class developer with a modularized code developer about 3 months into prototyping, all you need is a sudden change to the requirements to completely throw the former off balance. A modularized code developer is both more agile and more structured, period.

Regardless of whether you're a software engineer or a manager, try to frequently review code generated in your team. If the typical method tends to be longer than 20 lines of code or the typical class is longer than 500 lines, you must realize that your software operating expenses are going to rise very soon. Do something about it now. Have a talk with your peers. Start gently, but keep at it. Ask them why they think every responsibility has to be handled by one class or method. Explore ways to divide those responsibilities between re-usable modules and conquer the problem in ways that can be understood by any reader. Let it be known to everyone that in the competitive field of software, design requirements are ever-changing, and this: Gods are not disposable.

The entrepreneurial spirit of Software Management

I'm excited to report that my CMU teammates and I completed the first course in the Software Management program, the "Elements of Software Management" (ESM).

If you are interested enough to be reading this post, you are probably already familiar with the general overview of the program and are rather looking for insider information. I will try to break down that information from the following perspectives:

1. What you will learn inside your ESM class

Summarized in two words, the ESM course is about "Business characterization". In your first course ever in this program, your goal is to analyze the vitality of a randomly-assigned, publicly-traded software company. You have all the publicly accessible information on the Internet as research material, 4 books and 1 course reader as the means of learning the mechanics of how to research, three other partners in crime to collaborate with (who each are assigned their individual companies), 45 minutes per week of your coach's time to share among your team for seeking guidance, and weekly lectures to discuss readings with the class.

Although you have a team, the work is team-ish. This is only a warm-up course in terms of collaboration, so you are responsible for your own individual research. The team is there to discuss the learning process on a high level, but you produce results individually about your own target companies. The two months for this course are divided across different aspects of business characterization: An executive overview of the company, market analysis and business strategy, financial analysis and business prognosis. Most of those concepts were foreign to me before I had to dive into them. I found myself reading an average of 1.5 hours a day, writing 1 hour a day (mostly deferred till the end of the week) and spending 3 hours a week on collaboration.

Every week, or sometimes every two weeks, an analysis paper is due. The very last assignment was an 8-minute oral presentation of the researched company to imaginary executives, that is, the class instructors.

2. How your roles outside school might cope with the new load

Let me begin this subject by mentioning that I started writing this post 15 days ago. Balancing your family role, your job or career and your role as a part time student are not easy feats. In the last two months I have at times had to switch to damage-control gear and concretely demonstrate to those both at work and at home that I am still fully committed to them. I've had to skim chapter summaries instead of reading them in detail. I've traded some of my sleep for a well-researched late analysis submission on a Sunday night, a four hour commute on Monday morning from my girlfriend's place and showing up to work at 8:30am to show my team at work that they can still count on me.

Despite those moments of pressure, and without incentives, I like to write. I write because, to recite an anonymous quote framed on my girlfriend's wall, "life is not about waiting for the storm to pass. It's about learning to dance in the rain." I signed up for this program not to trade jobs, but to trade confusion for leadership. For two years I've contemplated that there must be a more direct and powerful way to make a change along the path I have chosen. I chose management because it would give me a leverage from a higher level to effect that change. A part of my commitment is to lead, and I know that there are hundreds of people like me out there who feel confused about what to do with their engineering careers. I write despite the pressure for time, because I chose to follow the passion for freedom of personal and social expression. I'm seeking my passion through learning to direct software development; and I know there are leaders out there without their wings. My fourth role is one that I have assumed individually: to be the seductive call, in the ears of the undiscovered software leaders of tomorrow, to the fulfillment of their true purpose.

Those are big words two months into a program, but I have thought them for 10 years. You know how sometimes you look at your agenda and there isn't much there besides work, yet you feel a huge burden? That's the burden of not meeting your potential. I still have as much free time as before the program. How? I learned to cut loose some of the heavy weights holding me down in the middle of this course. Instead of trying to fulfill my dreams in solitude, I now include my family and coworkers in my progress. Pointy-haired bosses call this finding "synergy". I call it becoming whole again. I distinctly remember the similar pleasure I experienced as a child when I discovered that, when painting with water-color, the yellow rays of the sun and the blue horizon of your ocean form a green color when they finally meet. My set didn't come with the color green, so discovering how colors reacted to each other opened up my eyes to new possibilities of painting endless forests and leaves. When you mix up the few colors you have, you get a whole set to paint with. To read more about the mysterious way software engineers relate to paint in particular, read "Hackers and Painters" by Paul Graham.

3. Whether you need to reconcile your identity

My typical week right now is very different from what it was in the past few years. I used to work for 8 hours, then come home and work up to another 8 hours on a start-up prototype. Nowadays I work up to 9 hours a day, reserve 3 hours for school work, and spend the rest of the time with my girlfriend. The main difference is that at school I try to learn about what might help my work, at work I pay attention to what might be a good case study at school, and at home I share most of my experiences with my girlfriend. You don't realize how fractured your identity is until its incompatible parts start to compete with each other for time. One reason I left Seattle for the Bay Area was to leave behind a lifestyle built around a fractured sense of identity and start a new one as a whole person. So far I feel I've been successful at that.

As an engineer, nowadays I look at my company from a new perspective. I used to look at my sphere of influence from a short-sighted point of view. I used to either want to integrate against cool platforms, optimize things that were functioning terribly but were not broken, and generally make life better for engineers. Since understanding the concept of branding, market segmentation and market-driven development, I have completely revised my system of "importance" evaluation. In my career so far I have never seen someone on the engineering side of a software company reason based on the impact of a decision on the balance sheet, income statement or cash. I have never heard of a developer point out how a cool project doesn't fall within the current strategy of the company, or suggest that a new application is too generic to be branded as something purposeful.

I now understand why several of my boot-strapped startup attempts have ended in failure: The first one attempted to compete with a large company (Facebook) in their own turf without hiding in a niche spot; and the second idea had no customer, purpose or branding strategy in mind - it was just a very cool idea waiting to be recognized. I now understand what turns off a VC and whether to run away when I hear "we want to become the next API consolidating XYZ data and we're launching our first app in two weeks. We're just looking for a rock-star engineer to scale it." (read: nobody recognizes us, but we want to become the standard that the currently recognized companies should follow, and we want you to spend 4% of your life time on this idea.) I kindly declined one such flattering invitation thanks to my new learnings just from this course, and several weeks later I'm helping some of the founders find work.

If I sound like my entrepreneurial spirit is defecting to the managerial world of conservatism and pessimism, it isn't. On one end of the spectrum, I look at people such as Dr. Stuart Evans, my coach this semester. As part of his research area, he studies the behavior of software companies of various sizes in different environments. While he has been involved with several software start-ups, he has not focused on the actual writing of software. On the other end, there are people like Bill Gates, Steve Jobs, Peter Norton, Mark Zuckerberg, Jimmy Wales and Craig Newmark, who knew most things about writing software and very little about business when they ventured to change the world.

There is no knowledge or merit you can acquire that will make you a wise Wizard or an experienced King overnight. Most good engineers I know have a similar personality to Aragorn, the lone ranger of the Middle Earth: anonymous, wise enough to listen and potent enough to move the world. And yet, they wait for the day when a higher power restores their confidence, the broken Sword of Elendil. As long as there are dark forces in this world, there is a place for those who embrace ingenuity: those who are neither all-wise nor all-knowing, but both ambitious and sympathetic, to put meritocracy aside and become a leader. There are problems to be solved, while the status quo of the world are solving problems that don't need solving. I call doing the right thing, in its technological contexts such as in this one, the "entrepreneurial spirit of software management".

Sometimes the only evidence that you are is what you feel when you stand against the wind.

Pattie Maes and Pranav Mistry demo SixthSense

Currently I'm swamped by the pace of deadlines: release after release at work, and company business research submissions one after another for the SM program at CMU.

Meanwhile though, on TED.com I found the following video about an innovation called "SixthSense" which I found absolutely brilliant. This will be a trend setter and shows how we're all going to be convinced to not only become cyborgs in a not so distant future, but also supernodes in a mobile social network. I very highly encourage you to watch it.