Recessions do some crazy stuff to product markets. When you have a recession, or in general when there’s a lot less spending going on by your consumers (businesses or people), the available revenue for all firms in the industry decreases. It’s sort of like rainwater collecting in a bowl. When there’s a drought, there’s less rain and less water collecting in your bowl. Consequently, there’s less water in the bowl at any given time, and only companies that are very good at drinking from the lower water levels can survive.

In economics terms, this ability to survive on less communal water has to do with something called cost optimization. Companies will always produce at the quantity where marginal cost (MC, the cost to produce the next level of output) equals marginal revenue (MR, the revenue you get from producing at the next level of output). Profit is the difference between the revenue you get at this intersection (point a) and where the point maps on the average total costs (ATC, all of the costs it takes to produce the good including the startup costs to get the company and operation up and running). This difference – positive being a profit and negative being a loss – is economic. It’s not just money; it takes into account essential things that aren’t easily represented on a balance sheet like how much time it takes to sell and produce a good or what the company could’ve been doing otherwise.

In this graph the company is operating at an economic loss: the amount of revenue they get for producing at output level q* is less than their ATC for producing at q* (see point b).
Now a firm can continue to live while producing at an economic loss point. Neither Google nor Facebook was profitable for a long time, and many of the big names aren’t making positive profits compared to last year. Maybe this company is a new tech startup and are still operating “in the red”, or maybe there’s a recession going on and the water isn’t as high as it used to be (the water being the little blue bar – the demand for the product and also the marginal revenue in a market where every product is the same, there’s lots of folks producing stuff, and it’s easy to get in and get out of the market). Producing at this level of economic loss isn’t that bad if you know you can get back to a break-even level or even make positive profits in the future.

But if you make less than the average variable cost (AVC, the average cost it takes to actually make each good and not just what it took to get the whole operation running) you’re in trouble.  Then you’re losing money/capital/hopes and dreams/whatever it takes to power the creation of you’re product on every sale. Death comes quicker here: you can survive for a little bit on when you’re bleeding from a pinprick, but at this point blood is simply gushing out of your company. Life does not look good for your company here, sport. Soon your operation will perish into the economic oblivion known as shut down.

This is where things get interesting – and profitable. If for some reason your marginal costs are lower to factor for the water drying up, or you’ve got a ton of money saved up, you can sweep up those firms that are shutting down with your extra cash and buy their tasty trade secrets and technology. In tech companies this is basically all of the secret sauce that makes everything so cool: intellectual property, the brilliant  engineers that made that IP, the secret machines and tools used to build shiny things. Just because a firm is suffering huge economic  losses or even is about to shut down doesn’t mean their technology isn’t valuable. Recessions are horrible for the unprepared, small companies that don’t have money in the bank to deal with them. But they’re awesome for the big guys that have billions stashed up and are ready to go on an acquisition spree. It’s a freaking fire sale in high tech, and everyone’s invited.

We’ve all seen this in the real world. Oracle acquired Sun, once one of the great software titans in the world but recently struggling with marketing and selling their products and servers in this recessionary market. With their “pennies on the dollar” purchase of Sun (a result of their stock being abysmally low compared to the early 2000′s) Oracle picked up a huge commanding share over the database market and the hardware IP to start taking over the data center. HP’s acquisition of 3Par worked the same way: take the struggling company, buy them up when they’re dirt cheap, and get some sweet technology and engineers to make better products that advance your market position down the road.

Now this usually isn’t a bad thing in economics. Sooner or later, as these big firms compete heavily and start to all “look alike” in their products, commoditization will occur and small guys can come in and start to get things more competitive. This is essential to innovation, the lifeblood of high tech. Competition breeds great technology and lower prices because companies have to work harder in delivering better products – lest they die. Without such a competitive market and pressures from Apple and Linux, it’s unlikely that Windows 7 would have been much better than Windows Vista. In a competitive market, Adam Smith’s “invisible hand” will make everything right once again and we’ll be back to low prices and high competition as usual.

Except that’s not how high tech works. High tech software (particularly web software) is generally competitive. But computer hardware, networking, and software industries protected by government exclusivity/top secret clearance requirements, are expensive to start a company in, or otherwise are extensively guarded by licenses and patents are not so competitive.

Many of these industries are oligopolies – places where there’s only a few guys around the block. You see this a lot in commercial operating systems: you buy Windows, OSX, or “purchase” Linux (i.e.:  paying the cost in crying over trying to fix it at 2AM in the morning when you rm -r‘d your home directory). You also see this a ton in places like processors. 99.9% of every computer you’d see at Best Buy is powered by either an Intel or AMD processor. The processor industry is actually frighteningly mired in patents, licensing, and high startup costs. It’s not very competitive because two kids in a garage can’t come in and dethrone Intel or AMD, unlike the market for mobile games or web services.

The recession’s effect on narrowing the market in key industries like computer hardware and networking may have very serious consequences for our ability to innovate in those fields. Without competition, companies will have less incentive to release better products and engage in daring feats of research to push the boundary. This isn’t good, because right now the laws of physics are catching up to us in these fields. Things like Moore’s Law – that predicted that effectively the processing power of a computer chip will double every 18 months – are starting not to apply anymore because it’s getting too difficult to make chips smaller and faster. Without incentives and an environment that’s easy to innovate in, we may see technology in these fields stagnate.

Have no doubts: stagnation is the death knell for any tech industry. High tech is a business formed on pushing boundaries. If you can’t move forward, you die.

This makes a certain amount of sense when you consider the amount and diversity of the information you’re working with. A PM has to be both evil suit and unkempt hacker – or at least enough of each to be able to fluently communicate with both extremes. If I go into a room with a software engineer and I can’t speak in algorithms and programming, I’m not going to be able to really interface with that individual and get the information I need. Similarly, not being able to understand finance and corporate strategy renders you completely useless and unintelligible to essential folks who work in both capacities.  Ultimately, a PM lives and dies by his or her knowledge of everything and anything related to how their product is created, sold, and ultimately received by both the customer and the competition. If you’re a know-it-all, you’re more likely to be motivated in your pursuit of trying to master everything.

And you’re probably going to miss a lot of stuff along the way.

One of the other big things I’ve learned as a PM is that you frankly can’t know everything. There’s no way in hell I’m going to be able to be as masterfully good at programming as my product’s engineers, nor am I going to be as much of an accounting and revenue projection wizard as my financial analysts. Sure, I can do a bit of both and look and talk the part on some days. But the reality is that I just don’t have the training/experience or spend as much time concentrating on either area to become a specialist in it as much of the people who do spend time on it and do train specifically to do that. If I try to take over and play developer or accountant/analyst when I can’t, I not only might screw up whatever I’m doing and not know it, I’m also wasting valuable time that’s more efficiently served by letting someone else just do their job.

This catch 22 of trying to know everything but recognizing you can’t extends far beyond the academic areas that govern high tech. It also plays into the market knowledge that’s core to what a product manager does on a day to day basis. When I first started talking to customers, I noticed that half the time I wasn’t really listening to what they were saying much as I was trying to validate assumptions I’ve made.

Again, this consequence of know-it-all-ism is pretty bad.  If I’m just using the customer and his/her information as a way of confirming or denying my own opinions, I’m not really learning about the market so much as I’m just going in circles around my own ruminations. If something changes I’m less likely to catch it because I won’t be listening to what’s going on. In effect, I’m going to miss the hidden message in the music because I’m only listening for a specific lyric.

Being a product manager isn’t about knowing everything. Absolute brilliance isn’t required for the job (nor is it feasible).  Instead, effective product managers are excellent communicators. I may not know the answer myself, but I can find someone who does and channel that communication in my strategy and in my messaging.

Brilliance is just knowing the right people and asking the right questions.

Darryl broke our reverie as he opened his tall can of Arizona Tea with a resounding pop. The echo trailed throughout the quiet night here on Skyline, a mountain road of blind turns and unguarded cliff sides leading to interminably long drops into an inky abyss. We rested against the hood of his nimble Miata at the top of the trail  after blasting through Skyline on one of Darryl’s favorite “runs.” While my hands still shook from the experience of gliding across the roadway uphill at highway speeds, Darryl was eerily calm. For him this was normal. Darryl was a touge driver – a particular brand of car aficionado who loved the thrill of navigating mountain roads. While he was married to Calaveras Darryl had an intimate and torrid automotive love affair with Highway 9. He drove it every other night after school and running the graveyard shift at a nearby ISP’s data center. He knew it like the back of his hand, instinctively coaxing the wheel into a turn without even needing to see signage informing him that something was coming up. It was his baby. It was his release.

Later he would die here.

This wasn’t the first time Darryl brought people up Skyline with him, much less CS Club members. As a harsh-speaking, tall black guy Darryl sort of stood out among the librarian glasses stereotypes of the Computer Science Club. He enjoyed this visual and cultural discrepancy, reveling in such differences and often wielding it like a weapon to socially push geeks out of their cloistered comfort zone. Taking them up driving with him was one of his preferred ways of doing this. Once you got to know Darryl fairly well, he would be more than happy to offer you the chance to ride shotgun with him. He was excited to share his love of touge with others, and it served the purpose well of pulling someone way out of their comfort zone. Tonight that someone was me.

After stopping for gas and some convenience store snacks in San Jose (Darryl made sure that I bought some powdered doughnuts and caffine for the trip – “n***a you need to f*cking eat”) we powered up Skyline. It began with Darryl flaring the sound system in his Miata to its max, nearly blasting out the speakers with fast-pumping Japanese rave music. Suddenly we were off, flying through this forested mountain road like a salmon darting upstream through the water.

My hand went white while it was gripped to a handle hold in his car. Skyline is a notoriously treacherous road, and while I heard Darryl was a good driver that didn’t stop me from looking down past the unguarded cliff side to try and find the ground beneath us. At several points I fiercely shut my eyes and tried to pretend I wasn’t on a 1.5 lane highway in the middle of the mountains with nothing but headlights to guide us. But every time I did, Darryl laughed and spoke up: “open your eyes dude, it’s ok.”

With his peripheral vision, Darryl was watching me the whole time as he calmly navigated Skyline. When I got too scared, he slowed down to nearly a crawl and reassured me that everything was okay. This was part of the Darryl not a lot of people knew: the guy who fiercely cared about his friends, the closet-geek math major who secretly enjoyed technology and mathematics because it was beautiful and fun.  He made sure to be reassuringly calm and collected throughout the drive, talking deep about his passion for driving and what it brought him. “All of it man, I love just me and this road,” he said as we flew into the night. “Anger, hatred, people getting all up on me – I go drive this shit and I don’t even care. I love this stuff, and I get peace out of it.”

I thought long and hard about this idea – loving something so much that you find solace in it – as we finished the run and stopped at the top of the mountain. Darryl’s love of cars was always apparent in the CS club, and he spoke with the fervor and passion of any other geek when describing the intricacies of his passion. But this was something different. Darryl’s passion was more than simply a series of goals or an obsession, it was a cathartic release from all of the world’s problems. When life bore down on Darryl he just got in his car and drove, and everything would fade away into the beauty of the drive.  That kept him balanced, and that made everything okay.

It was zen in the purest of ways. Darryl had found in his art his way of attaining mushin – the “no mind.” Darryl was in control of everything through his passion, and by channeling it he found more than simply solace. He found his peace and clarity through the happiness of a drive. He found it in beauty – his beauty.

As he saw me compiling and reviewing this all in my head, he gulped down some of his Arizona and took a drag off of his cigarette. “That’s what it’s about, man. It’s about finding what you love and just doing it. Driving, coding, whatever you want. I just do stuff like this and I’m happy. I don’t give a f*ck. I’m free.”

Darryl taught me a valuable lesson that night. Through his friendship, Darryl had already lent me the value of confidence and a perspective and vocabulary valuable in other environments than the Computer Science Club. But tonight, on this mountain side, Darryl taught me something dramatically important.

Happiness is simple: it’s just enjoying the beautiful things that you love.

Luckily the world is filled with more than enough beauty for all of us to enjoy. I realized that as we shared this image of the Bay glowing beneath us under brilliant winter’s moon.”Wow man, it’s really beautiful up here,” I whispered.

“Yeah,” he sagely nodded. “Yeah it is.”

Thanks for the lessons Darryl. Rest in Peace.

The property or statement is true because the question is worded “Prove the following.” QED.

Proof by lecture:

This is the exact same problem from the lecture yesterday. You’re simply reusing it because you don’t want to write new questions. QED.

Proof by intimidation:

I assert that the above statement is true because I have both an incriminating video of the both of us drunk and naked and the e-mail address of the dean of students. QED.

Proof by Vin Diesel:

This above is true because Vin Diesel says it’s true. QED.

Following the competition I searched for a very tall building to jump off of, but I’m in San Jose so even that didn’t work out very well.

Here’s my code for ThemePark. It works with the small input sizes:

import java.util.*;
import java.io.*;

public class ThemePark
{
public ThemePark(String path)
{
try
{
theFile = new Scanner(new File(path));
}
catch (Exception e)
{
System.out.println(e);
}
}
public static void main(String[] args)
{
ThemePark park = new ThemePark(“C-small.in”);
String line = park.theFile.nextLine();
int numTestCases = Integer.parseInt(line);
for(int i = 0; i < numTestCases; i++)
{
//Run a test.
String definitions = park.theFile.nextLine();
String[] defs = definitions.split(” “);
int R = Integer.parseInt(defs[0]);
int K = Integer.parseInt(defs[1]);
int size_N = Integer.parseInt(defs[2]);
String definitions_N = park.theFile.nextLine();
String[] queue = definitions_N.split(” “);
int[] g = new int[size_N];
for(int j = 0; j < g.length; j++)
{
g[j] = Integer.parseInt(queue[j]);
}
RideQueue coaster = park.new RideQueue(g, K);
int revenue = 0;
for(int n = 0; n < R; n++)
{
revenue += coaster.getRevenue();
}
System.out.println(“Case #”+(i+1) + ” “+revenue);
}
}

Scanner theFile;
public class RideQueue
{
public RideQueue(int[] g, int k)
{
riders = new LinkedList<Integer>();
for(int i : g)
{
riders.add(i); //You can’t deny it, I’m a f*#%in rider, you don’t want to iterate with me.
}
capacity = k;
}
int getRevenue()
{
int res = 0;
int current_capacity = 0;
int passengers = 0;
String status = “Passangers: “;
for(int i = 0; i < riders.size(); i++)
{
passengers = riders.get(0);
if (current_capacity + passengers <= capacity)
{
res += passengers;
status += passengers + “, “;
current_capacity += passengers;
riders.addLast(passengers);
riders.remove(0);
}
else
{
System.out.println(status);
return res;
}

}
System.out.println(status);
return res;
}
LinkedList<Integer> riders;
int capacity;
}
}

Being a finalist in Imagine Cup has been an amazing experience. Watching Tesla go from seventy quickly-scribbled lines of C# and an ugly-as-sin GUI to over a thousand lines of code (not including the server) that evoked “oohs” and “aahs” is an indescribably satisfying thing. Tesla wasn’t even the best in show too; the quality of work and brilliance of the folks I had the pleasure of meeting at the finals was nothing short of astonishing.

While technically the whole thing was a competition for prize/seed money and a chance to represent the US in Poland for all the marbles, I never really felt like I was competing against the people I met there. Despite the variety in topics – health care, climate change, women’s rights – each team was less in competition with each other and more locked in combat with the difficulties of bringing their ideas to fruition. We all fought the same battle to bring our work from pipe dream to polished and productized solution. And there was unity to be found in such a fight.

So as I sit here homeward bound a plane somewhere over the Appalacians (note: I’m posting this up after I land), remarkably sleep deprived and searching desperately for the words to try and recount what happened in an enjoyable and semi-comical kind of way, I feel like maybe talking about what actually happened isn’t the best way to approach it.  It’s not really the exact details that are important so much as the moral of the story – the grand lesson imprinted on one as they watch their crazy idea become a reality:

If you work absurdly hard, dare to be radically innovative, and really believe in yourself, you can do pretty much anything.

It’s easy to let the world get you down when you’re working on something hard that nobody’s done before. Tesla was no exception. In the last few months I was dreading having to deal with a lot of the technical issues around getting Tesla’s statistics to be accurate. Trying to find a way to model difficult things like GPU power consumption and figuring out how to measure processor utilization without Tesla demanding too much from the system and corrupting the sample (read: total Heisenberg Uncertainty Principle action) has been something that’s kept me up at night. There wasn’t a guide to figure out how to do all of this: it just came down to hours of grueling work and a lot of luck.

It gets worse though: there’s just no time to do any of this. All of the Imagine Cup competitors were in college, and each of us had to put parts of our lives on hold to get to this point. Balancing developing Tesla against studying, midterms, homework, my internship, and not becoming a shut in has been extraordinarily difficult. It didn’t end when we got to the finals. I know I wasn’t the only one who had to go do homework or study at 3AM after all of the day’s events were done to keep up. Against such challenges it’s been very challenging to find the audacity to stay hopeful and keep fighting.

But in the end it paid off: a free trip to DC, symposiums on technology that’s still deeply mired in NDA, tons of press coverage, at least one enjoyable opportunity to rage, and all of the exposure and contacts necessary to make such crazy ideas a reality. Even though Tesla didn’t win, there were a lot of folks from Microsoft and other companies that found our business plan compelling and wanted our technology. This isn’t something unique to Tesla; almost all of the Software Design projects were looked upon very favorably by Microsoft, their guests, and the press. This kind of favor translates cleanly into funding opportunities, and such resources mean that you can really go out and accomplish your goals of saving the world.

As the last of my friends from high school graduating college, I’ve had an opportunity to hear a wide variety of stories about just how lackluster the real world can be. Having been interning and working throughout undergrad, I’ve even seen a bit of it myself. Even in the magical fairy land of high tech there’s still plenty of depressing truths and harsh realities that can turn the most idealistic geek into a dismissive and cynical misanthrope.  Our world is not perfect. Hell, it’s not even really that good sometimes. Rendering change in it often requires herculean effort and similarly divine luck.  But it is possible to change the world for the better. Events like Imagine Cup reinforce this fact and provide lucky and driven students with progressive passions the opportunity to do just that.

Being a finalist in Imagine Cup gave me a lot of stuff. I got shirts, backpacks, and tons of other swag. I met a ton of exciting folks, picked up some new business contacts, and made some friends with a group of amazing people. But personally, Imagine Cup gave me something else: hope. All of the finalists took some crazy ideas and turned them into solid, real solutions to some of the world’s hardest problems. We overcame wild adversities – both technical and otherwise. We pushed on despite immense challenges to create things of beauty. If we were able to do this, we can pretty much do anything.

The world has a habit of being a pretty bad place sometimes. Luckily, we can change that.

The text is as follows:

they lied to us.
this was supposed to be the future.

where is my jetpack.
where is my robotic companion.
where is my dinner in pill form.
where is my hydrogen-powered automobile.
where is my nuclear-powered levitating home.

where is my cure for this disease

The real world sucks. No, really. It sucks. It’s nothing like college. There’s no Thursday night partying. You don’t get to sleep until noon. Not turning in work on time has dramatic consequences. And, unless you’re an engineer, it’s pretty hard to reconcile wearing torn jeans and flip-flops into meetings. Life in the industry, while much more luxurious than the Top Ramen-infused experience of college,  is filled with a myriad of new challenges and responsibilities that will ultimately rob you of the beautiful freedom from expectations and responsible behavior that many of us have enjoyed for the past four years or so. But this isn’t the worst part of it.

What really sucks about the real world isn’t that we suddenly get all of these luxuries we had in college taken away from us; it’s the stark and sometimes horrible realization that the idealistic goals, hopes, and dreams that many of us had as kids were predicated on a world that doesn’t exist. It’s really not as easy as “work hard – get a return,” and there’s a lot to our futures that ultimately lies out of our control. The real world is often not a beautiful place, and the cost of changing it and making a difference is high. Very high.

I’ve always wanted to make a difference in high tech by bringing geeky passion to an effectual senior leadership position – bringing the “geek” into the boardroom. To have the opportunity to do what I want to do with my career I needed to score a good position that’ll allow me better leverage with getting into B-School (in addition to the whole “score well on the GMATs” and “get letters of rec from amazing folks” deal). There’s a few different jobs out there that allow me to do this, but being a product manager was always the ideal. As a PM you play general to how your product goes to war. You manage engineering, financial, and marketing resources in order to bring a product to market and ensure that it beats its competition like it’s playing Punch Out with cheat codes. It’s the greatest place to learn how to manage a variety of interdisciplinary aspects of high tech company, and it looks really neat on a resume.

Getting to be a PM as a new college grad is pretty hard to do. There’s a lot of power there, and given how much of an impact you have on a company in this role most organizations are unwilling to entrust a fresh college grad with so much responsibility. But I got lucky. Working through school and leveraging a good relationship at a company I worked at as an engineering intern allowed me to get a PM internship there. Now, as my internship winds down and I embrace full-time, I get to be the real deal. Thanks to a lot of luck and hard work I get to prepare for grad school by having the job I always wanted. I’m going to be a product manager. I get to make a difference – I get to live the dream.

But the dream is hard. Really hard. Because most of my development team is in India, every meeting I have with engineering s is at or around 6:00AM Pacific Time. This time’s not super great for them either. 6AM PST is usually around 7PM the next day over there, meaning that they stay pretty late in the office to do meetings with our corporate office over here.  Waking up early wouldn’t be that bad if I wasn’t up late working. But because there’s a lot to manage there’s also a lot of work to do on even the most placid of products. This equates to long hours during the day where you’re meeting with folks to communicate your vision. And for me, who’s still got another month left of school and is doing this simultaneously, this means that all of my work as a PM comes at the cost of pushing back what I do for school until later in the evening. If I stay up till 2AM doing homework and studying, that leaves me little time to sleep before a 6AM meeting. The result: no sleep, lots of work.

Even though it sucks sometimes (especially now), I still like my job. Being a PM really is the best job I could have to help me get into business school with the intent on building a MBA targeted at high tech leadership. And hell, even having a job right now is a pretty nice luxury for a new college grad. I admit though that like a lot of my friends I’m a bit dismayed with how the “dream” has turned out. Never really knowing enough about your product? Going off of little/no sleep for long periods of time? Never really having complete control over everything that goes on? Being forced to make huge sacrifices in your personal life to just be baseline functional in both work and school? This is dramatically not the life I imagined when I dreamed of being a product manager.

There’s a very serious and implicit danger here with all of this: the danger of becoming cynical. I think that the youthful idealism that drives a lot of us really is really a precious commodity. Cynicism is a poison that nullifies youthful idealism, and in addition to the social implications of misanthropy it kills your drive because you think that the change you can render is ultimately inconsequential. I’ve noticed that a combination of fatigue and dismay at how things really are makes it very easy to become cynical. This ease in difficulty makes cynicism a very attractive alternative to the desire to “rage against the dying of the light” and remain positive in the face of such adversity.

But we have to. I have to. Just because the future didn’t have nuclear powered houses or jetpacks doesn’t mean that we still can’t make a difference in it. The fight may be harder than we thought, but that doesn’t change the fact that we can still do great things if we work hard enough. And even though it’s bad at times – even though we occasionally go days without any real sleep, we feel like we just want to give up because there’s nothing left, and sometimes we want to throw it all away by  just dismissing our childhood dreams as overly lofty goals and go with the easy solution of cynicism – we can’t. It’s criminal to give up all we’ve worked for to lose hope. We do ourselves a disservice in discarding our dreams by becoming cynical.

When the going gets tough the tough get going. However, I think that part of being tough is keeping hopeful and driven by rejecting the sometimes startlingly negative nature of circumstance. I firmly believe that there exists a method to be successful in one’s career and still come out of the fight a good, hopeful, and loving person. I just have to go find it.

Brittany recently started to try and get in touch with me after she found my dad (her uncle) on Facebook. It was frankly kind of weird to talk to her after wall of that time. She looked nothing like the memories I had of her, and our communication was strained by the harsh realization that both of us were sort of strangers now thanks to the mercurial nature of experience and life. Nevertheless, Brittany pushed hard to try and reconnect. She sent me messages, tried to chat with me on Facebook’s buggy IM client, and even left me posts on my wall.

Unfortunately, I was never there. Every time Brittany sent me a message I was away from my computer. Worse, when I was there I was always heading out to go do something. Brittany would send me a chat message, and I’d always fire back a “hey, i’m about to leave” or “yooo I gotta go – ttyl?” Honestly, I gave Brittany’s attempts to reconnect far too little heed than they deserved. I thought that I’d get another chance to talk with her when I wasn’t busy and put dedicating time to communicate with Brittany on the back burner.

But I was wrong. There wouldn’t be another chance, and Brittany would die before I’d really get a chance to reconnect with her.

I can’t help but feel like maybe Brittany knew her time was coming. Maybe her avid attempts to reconnect were because she wanted to set things right before she passed away. This makes me feel horrible because it’s my fault that we never had that opportunity. I was always too busy with my job, school, or my social life; I never made time for her because I was always so damn sure that I’d get another opportunity. I know that logically I can’t confirm any of this because so much of this is based on weak inference, but the computer scientist and mathematician in me is sort of taking a back seat on this one: in my heart I know that I could’ve done more and I didn’t.

I pick up a lot of things from my friends. How I deal with failure and personal shortcomings is no exception. I copied my friend Edlyn’s way of dealing with stuff like this because she traditionally had her shit together and her method was more structured: objectively assess what I did wrong, formulate a strategy, and execute. This method works wonderfully for academic, professional, and sometimes even personal failures. It allows you to address your shortcomings and ensure that you minimize the probability of making the same mistake twice by improving yourself. But Edlyn’s method frankly breaks down for me when the failure is particularly egregious. It’s easy to discount that the damage is already done for what you’re responsible for, but when the damage is pretty fucking bad it’s sort of hard to just dismiss it all to the past and move on. This is one of those cases.

Still, it’s all that I’ve got, and I’m trying to stick with the plan on this one.

When I was in high school I read a lot of poems in Latin by a guy named Horace. Horace is famous for Carpe Diem, a phrase that means “sieze the day.” This is a quote from his 11th ode (song/poem), a very epicurean piece that talks about how to live life given one’s knowledge of their mortality. I’ve put a copy of the poem below and translated it:

Carmen XI:

1. Tu ne quaesieris, scire nefas, quem mihi, quem tibi
2. Finem di dederint, Leuconoe, nec Babylonios
3. Temptaris numeros. Ut melius quidquid erit pati,
4. Seu pluris hiemes seu tribuit Iuppiter ultimam,
5. Quae nunc oppositis debilitat pumicibus mare
6. Tyrrhenum: sapias, vina liques, et spatio brevi
7. Spem longam reseces. Dum loquimur, fugerit
8. invida Aetas: carpe diem, quam minimum credula
9. postero.

Do not seek to know what end lies for you or me, oh Leuconoe, nor consult the charts of Babylonian seers. Whatever it shall be, it is better to bare it. Whether Jupiter shall give you many more winters or if this one shall be your last, one which now breaks waves on the shores across the Tyrrhenian Sea: be wise, strain the wine and cut back your long dreams to this short  time [now]. While we speak, envious spring (i.e.: what little time we have left) flees. Seize the day, trusting little in what comes tomorrow.

Horace in Carmen 11 cautions Leuconoe to not try to figure out when she’s going to die. To do so is folly: such knowledge is forbidden (unobtainable in the least, denied by divine providence in the most extreme case) and is frankly folly given that even Horace’s rebuke of Leucone’s efforts is wasting what little time they both may have left. Rather than obsessing about death, Horace tells her to live life now. Don’t set up lofty long-term goals or procrastinate your desires because you think that you’ve got time. Don’t trust your assumptions that tomorrow’s coming: you really don’t know how much time you’ve got left.

What I can learn from Brittany’s passing is what Horace is talking about in this poem. At the end of the day, we really don’t know what little time we’ve got left. I can’t just put family and friends on the back burner because my career or my school is excitingly demanding at a particular given point in time. Life isn’t about how far along I am in my career or stuff like that. Life is about lasting relationships and truly living – things that fucking trump comparatively impertinent (and sometimes innocuous) bullshit like some of the things I’ve been obsessing about.

I won’t make the same mistake again. I’ll make time for those that I care about and not procrastinate the opportunities I have to live. I’ll do better at balancing, school, work, and life.

But man, I really wish there were better ways to learn lessons like these.

Ada Lovelace was born into one prestigious intellectual pedigree. While her name is taken from her noble title (Countess of Lovelace), Ada’s real name is Augusta Ada Byron – the daughter of the famous English poet Lord Byron. Her father died when she was young though, and Ada quickly moved away from her family’s literary roots into the exciting and nascent fields of number theory and computational theory despite being mostly bedridden due to sickness throughout her youth. Because of the period’s sexist take on education and her health, Ada was taught by homeschooling for most of her life.

Her homeschool teachers were pretty amazing though: Augustus De Morgan (a famous logician and the creator of the well-known De Morgan’s Law), William King (her future husband and famous physicist), and Mary Somervile (the lady who kicked off modern microbiology and fused math with science for the first time). Somervile later introduced Ada to a guy named Charles Babbage, who seduced Ada’s intellectual desires with a nascent field called “computation” and a wacky theoretical concept known as an “analysis engine.”

Ada’s work with Babbage revealed just how much of a smart cookie she was. Babbage is known for coining her the “enchantress of numbers” because Ada was able to fluently move between arcane and abstract mathematics and communication and writing. To get up to speed on Babbage’s work, Ada translated a piece of work on the engine from an Italian mathematician who wrote about the analysis engine as part of his dissertation. But like every other hacker out there, Ada sort of nerded out on it and started adding her own stuff to the translation in the form of footnotes. Eventually, her footnotes vastly outnumbered the lines of translation she grabbed from the Italian text. Babbage noted that Ada was going far above and beyond simple translation, and together they worked to refine his analytical engine and find mathematical applications for it.

The analytical engine – the first computer – would be a hulking mass of churning gears when Babbage eventually created it. In the prime of Ada’s intellectual life though, the engine was confined to designs and specs. Not having a physical copy in front of her didn’t stop Ada, and she used the designs to create complicated mechanical algorithms to calculate complicated stuff like the Bernoulli Series. In this respect, Ada was the first computer programmer. When Babbage later created the Analytic Engine (and his famous Babbage Counting Machine – the foundation of World War 2 era cryptological engines), Ada’s “programs” were some of the first calculation executed on this hulking gear behemoths to do everything from calculate bombing trajectories to help crack ENIGMA.

Given that she did all of her coding without a compiler (or even a computer!), one could imagine how badass Ada would have been on TopCoder or in the ACM ICPC.

Without the research in cryptography and computing done by Turing in World War 2, we wouldn’t have the modern computer. Without Babbage’s counting machine, we wouldn’t have Turing’s work. And without Ada, Charles Babbage would have just been some crazy guy talking about a mythical gearbox that calculated stuff.

Without brilliant women like Ada Lovelace (who now has her own programming language named after her), there would be no computer programmers. Hell, there might not even be computers.

Respect, Mrs. Lovelace. Respect.

Designing your development cycle is important. How I structure the development process of my software will dictate whether I can win or lose in getting incumbency over a market. But as a programmer (and now a PM), I think that we as an industry put way too much emphasis on where we lie on the Agile to Waterfall line. The level of absurd fanaticism around being an Agile firm or a Scrum firm (a crazier version of Agile where – take a look for yourself) is, well, absurd. Even still, having people trash on Waterfall because it’s old is just as wack.

I’ve heard stories of people rejecting offers at great software companies because they’re not “Agile.” To not run either Agile or another development process is seen as a stark indication that your company isn’t innovative. This is an erroneous assumption. On the contrary, there are a ton of firms that need the strict differentiation between test and development that Waterfall brings in order to get to market with a product that doesn’t break thirty seconds after you start using it. Video games are a great example of this; if you have an excellent PM, dev, and QA staff, Waterfall expertly compliments the whole Pre-Alpha to Post-Beta/Going Gold process that is the industry standard.

It gets worse when a firm tries to use a development methodology as a cure-all for their problems. There are tons of urban legends out there of companies who hire a Bain or McKinsey consultant who says that they should adopt Agile or Scrum in order to better go to market and hopefully increase competitive advantage / increase revenues. The reality of such a decision though is an immediate organizational cluster-f*#k that amounts when you stick a gun to the back of your developers’ heads and force them into bullpens. The effect should be similar to what happens when you conduct a merger on a smaller scale. Some groups do things differently, and forcing them all to become dramatically intimate with each other and violate their standard operating procedure may have the reverse effect of what you intended on profits and go to market time.

Or, if you adopt Scrum randomly, you may start to set up a culture of elitism and silo-minded thinking between development and other departments within your company. Everyone who’s not a “pig” suddenly gets looked down upon because they don’t get to talk during meetings. Even then, PMs get the shaft in this example because as the Voice of the Customer (i.e.: the only chicken that can talk) you can’t really render any engineering-side changes. For a derivative of a methodology that’s supposed to improve cross-functional change, Scrum does the exact opposite by institutionalizing the elitist authority of the developer and stifling the necessary communication from outside of engineering needed to tune a product to actually solve problems present in the market. Software development is an interdisciplinary process and not just the sole property of engineering.

It seems to me like we should just ditch all of this BS about being Scrum or Agile and create a very loose model for how software should be developed. Instead of drinking the cool-aid from consultants, I think that a CTO / CEO/ COO / other hands-own C-level executive should really just do three things:

• Ensure that there’s a lot of communication among development/QA and between dev/QA and the rest of the company. Critical to this is ensuring that there’s an egalitarian culture based off of merit – not whether or not you’re an engineer (*COUGH* Google *COUGH*) or in sales (*COUGH* IBM *COUGH*).
• Work hard to provide engineering with the resources they need to innovate.
• Create test and development plans that coincide with the product you’re trying to create and not because it’s cool or hip.

That’s it. None of this chicken or pig BS. None of the buzz-words. ‘Just do these three things and work hard on the actual business of making quality software. A good software design methodology, by any other name, smells just as sweet.