nhashem

Unfortunately I don't have much to add to the OP, but I wanted to comment on this. Everyone I know that hates Perl had some sort of experience where they inherited some legacy Perl script that broke all the time and yet performed business critical functions. I started my first full-time job in 2004, and whenever I get together with my old co-workers we'll STILL talk about the battle scars we had trying to bubble gum and tape together a particular script called cc_processing.pl (yep, just as critical as the name implies), that seemingly broke every other day and went so far down the rabbit hole you had no idea how it ever ran successfully. $a{$a} = $a->{$a}? Sure, why not.

I wonder how much of Perl's reputation is based on these kinds of formative experiences. I love Perl, but I'm realizing that everyone had their nemesis in sitecounts.pl, or traffic_reports.pl, or partnerpayments.pl, or wtf-how-did-this-ever-work.pl, and unfortunately didn't draw the same conclusions about Perl that I did.

We could debate whether this would "work" on a practical level as if this was a Powerpoint presentation for Steve Ballmer and we're supposed to predict how he'd react. But I'm really just finding myself appreciating the "space/science fiction" metaphor for technology.

Steve Jobs has often quoted Apple as "advancing the human race." I feel like this takes it to the next level. I felt myself wanting this company to exist just on pure principle. Whenever I read older science fiction, occasionally I'll recognize the story is supposedly set somewhere between 2000-2100 A.D., and yet we wear spandex and zoom around with FTL travel and fight aliens with lasers and make food with replicators, etc. And I'll smirk and think, "heh, he was way off," but beneath that cynicism, there's just a bit of regret that we just didn't actually evolve in that way. And I guess this is why the branding here resonated with me so much -- it touched that part of me and convinced me that this company could make all that reality after all.

As an engineer I feel like I have a hyper-literal mindset where most branding and advertising just washes over me. I live in a world where it matters what things "do," not how they "feel," so some guys playing volleyball with girls in bikinis while drinking Coors Light just washes over me as a bizarre way to stay hydrated while at the beach. But as I said earlier, I wanted this company to exist. I wanted to feel the things that this branding made me feel. I wanted to strap myself into this spaceship that this company was building and fly wherever it would take me. Practically speaking, that company probably won't be the one we all know as the bloated monopolistic entity that makes most of its profits from boring office productivity software.

But this made me wish it was.

I think the OP makes some excellent points, but unfortunately he uses the phrase "no risk" instead of, as I'd phrase it, "dramatically less risk." There is definitely opportunity cost. At the beginning you won't have an income. If you're 30, like myself, you'll watch your friends who didn't go down the same road start to pile up "stuff." Cars, houses, whatever. They'll have it and you won't. Even if your startup turns a corner to provide lifestyle income, there are still issues. This is a purely anecdotal example, but yesterday my wife and I went to a bank to talk about pre-qualifying for a mortgage loan, and apparently you need two years of self-employment history.

But here was the point that I think got lost in such a binary stated view of risk: right now it's easy to jump back on the totem pole. If I really wanted to buy property that bad, I could get a job making well over my previous salary within weeks. There are not a lot of entrepreneurial endeavors where that is true.

Consider something like opening a restaurant. There is not just opportunity cost but real investment cost before you even get started. And if you bomb, and statistically it's very likely you will, there is not nearly the the likelihood you can at least go back to where you started. As another anecdotal example, my friend is a second year lawyer at a firm, one of the few people in his graduating class that got a nice corporate law job so that he actually has a chance to pay off his massive loans. And he pretty much hates his life, but there's a huge chance that if he left to pursue one of his dreams, there would be no "reset" button. There is no easy chance that if he doesn't succeed, he can just go back to being a highly compensated corporate lawyer within a few weeks.

So yes, there's obviously risk in starting your own startup. There's always a cost to pursuing a dream, and not everyone wants to pay that cost. The distinction is as a technology startup founder in this current environment, your cost is dramatically lower than anyone else's, and I think that's ultimately what I think the OP is trying to say.

I feel this story demonstrates one of the "emotional vulnerabilities" of Lean Startup/MVP movement. You're going to crank a product out and then you expose it -- whether it's deliberately marketing it, pitching it to investors, showing it to friends, etc. You expect to hear something back like, "great concept, bad implementation," and so you just gradually improve the implementation until people stop thinking it's bad.

But sometimes you'll hear, "terrible concept, so I don't even care about the implementation," and that can be very demoralizing. Really, it should be taken as, "your implementation is so bad that I don't get the concept," which requires the same iterations of "improve the implementation." But it's too easy to basically just hear, "you guys don't know what the hell you're talking about so why don't you stop wasting everyone's time, including your own."

As we so often quote to ourselves: "your startup idea idea is worthless by itself." But that's not entirely true. Startup ideas indeed have no value to anyone by themselves. But they must have worth to the startup founder, because without that burning desire to solve that particular problem, how can a startup founder have the mental fortitude to persevere when their first iterations get very negative feedback?

This is actually a great mental exercise for determining if you're fundamentally unhappy at your current job. Just try and imagine your boss calling into a meeting like the one the OP describes and giving you some sort of, "your work has been good, but unfortunately we have to make some changes, and this will be your last day" speech, and imagine how you would feel.

If your reaction is something along the lines of relief, then you are fundamentally unhappy at your job. You have not only concluded that it is not a good situation, but that the situation is incapable of improving. It's likely only artificial mental restraints keep you from doing anything about it ("oh man I may have to move, moving is annoying... and I guess I get paid pretty well, most of my friends are making half what I do... and my boss said some things would change, although he said that months ago...") and those restraints aren't even that strong, otherwise you wouldn't be relieved if you got laid off.

I find the "brogramming" thing fascinating because I've never actually met anyone that has called themselves "brogrammer" non-ironically or non-satirically. My best friend's cousin is from Long Island and he has cousins that call themselves "guidos" and intentionally live up to every Jersey Shore stereotype because they legitimately think it's cool. My experience is only anecdotal, but I've yet to meet anyone who has actually used "brogramming" as a serious label for themselves.

My own personal theory is that there are two collective phenomenon at play here:

1) There's a self-cyclical force here where some people think brogramming is a label some people use non-ironically, so there are things like marketing materials developed specifically for it, which by definition will be exclusionary and sexist. This material further spreads the idea that "brogrammers are real" and everyone gradually forgets that nobody is actually this ridiculous.

2) There is a fear among programmers that our wonderful merit-based community accepting of all genders, cultures, and creeds -- which it is, really -- is going to turn into Phi Delta Toolbag overnight. For a lot of us, myself included, we've never been one of the "cool kids" and found computers and technology a much better fit for our introverted personalities. And suddenly these pink popped-collared polo shirt sunglass-wearing monsters are going to take that away from us.

Anyway, I understand why the women at UPenn would be offended by the "brogrammer" term, sometimes you just don't want to be associated with a term even if it's satirical. But are there actual brogrammers out there being sexist, or is this an overblown issue?

My understanding of YC is that applying with more than an idea was pretty much necessary to actually validate the idea. Having an actual live product, with some semblance of customers and/or revenue, made for a much stronger application and a much stronger pitch in general. I imagined that a lot of startups that were accepted into YC effectively got feedback along the lines of, "this is a cute app with some impressive technology and it seems like some people like it, so why don't you pivot to this concept that has a much stronger change of scaling," or something along those lines.

So if these applicants don't have an idea, then are they expected to not have any sort of work on a product? And if so, doesn't that make it a lot harder to evaluate their body of work and quality of their team?

I'm probably the wrong audience for this story, just like I'm sure doctors are the wrong audience for Grey's Anatomy. Just like a doctor would think, "this show makes it seem like doctors have sex constantly in storage closets," I'm thinking, "what VC makes and closes an offer with over the course of one meal?"

Still, entertaining read, thought it was clever the way email and tweet graphics were used throughout.

When I was in high school (late 90s), they had kind of a weird curriculum for teaching programming. We had AP classes for Computer Science A/AB, which you had to be at least a sophomore to take. There was also a class called 'Computer Programming' that anyone could take, which I did as a freshman, although the students in the class were actually pretty evenly distributed between all four grades.

Basically we were taught QBASIC and given assignments. The first few weeks seemed pretty mundane as the OP describes, getting into conditionals and loops, etc, but after we learned those, my teacher told us to make something like 'Choose Your Own Adventure' text-based game. I remember loving that assignment and even compiling it as an EXE and sending it to my other friends. This pretty much followed through the whole year, learning some new programming concept (arrays, functions, etc) and then making some sort of game as an assignment. We had the usual "write a program to display all the factors of a number" assignments too, but I just remember loving the game projects. I didn't know anything about Big-O or AVL trees or whatever, just that I could create cool stuff on a computer.

In 10th grade I took Computer Science A, and about half the class hadn't taken Computer Programming already. The material was a lot drier, obviously, and I remember a lot of those students switched out. I witnessed the same thing my freshman year of college -- no 'Choose Your Own Adventure Games' as an assignments, just grueling midterms on polymorphism and inheritance.

So this post really resonated with me, because my thoughts have basically echoed this for awhile -- why isn't software engineering taught as a discipline that can let you implement and create, since that's exactly what it is?

Online dating is a sausagefest. It's the biggest sausagefest ever. I'm not basing this on any scientific or quantitative information at all, just my own personal experiences from online dating from 2004-2008, the end of which was when I met my now-fiancee.

The "sausagefest syndrome" is inherently why so many online dating sites suck. Guys sign up and get barely any responses to their profiles or messages. Girls sign up and get immediately overwhelmed with messages, some interesting but the rest mostly boring or creepy. Guys get frustrated at the lack of traction and leave. Girls get overwhelmed by too much attention and leave. It doesn't help when the online dating sites start using fake profiles and pictures to give the false illusion it's not a sausagefest.

I've seen friends sign up for Match.com and be like, "this sucks, they have no matches for me," and then I find they're looking for half-Asian half-Russian college-educated non-smoking dog-owners in a 2.5 mile radius, or something like that. That's almost guaranteed to not work. Unfortunately the alternative is some sort of "shotgun strategy," which if done poorly, means sending a message to 50 girls with the same copy-pasted canned sentences, which only contributes to the women being overwhelmed. You still need to aim the shotgun. I effectively had a routine where I'd spend an evening looking through profiles, only ruling out absolute deal-breakers, and then sent a message that while mostly short, at least made some reference to the actual girl. Out of 20 messages I'd get like 5 responses, which would lead to 2 phone calls, and probably 1 actual date. Rinse, repeat.

Yeah, it's kind of annoying to fill out a profile and all that, but to me that's never been the problem. I feel there's a lot more social friction to get women to sign up for these sites, because while online dating to guys is basically, "well, why not, it's another possible way to meet girls," to girls it's, "this is admitting I am incompetent at/undeserving of finding love." Until that's overcome, online dating will always be a poor experience for a lot of people that try it.

How do you overcome it? In a drunken night with friends a couple months ago, I started rambling about an online dating site that embraced the male-female disparity, and basically would pair up something like 3-4 guys to every girl, and set up dates where you'd all go out like "The Bachelorette." There's a lot of reasons why that idea would be a hard sell, but if anyone ever does successfully do it, just make sure to give me my cut[0].

[0] http://xkcd.com/827/

I disagree. Hackathons are sprints, and just like have the occasional sprint workout can be a great way to augment your distance running routine, hackathons can be great for augmenting your software development routine.

Here are some reasons why I like taking part in a hackathon event (assuming the goal is to produce some sort of web application):

- Tradeoffs are easy. You have no time for bells or whistles. You consider a basic feature list and start working. If a feature starts to take too long to implement it, you just axe it. You probably end up with something that doesn't have many bells and whistles, but the key distinction is you end up with something. I can't tell you had some many side projects I've worked on had some painfully implemented bell that was pretty cool, but was pointless because I never got any core functionality working.

- All you can do is use what you know. In one hackathon group I was in, I was the guy who ended up knowing the most sysadmin/web server stuff, and the guy who knew the most HTML/CSS/JS. So I basically did my best to manage through installing/configuring everything at the server software level, and then mucked around with some CSS templates trying to shoehorn it around my team's application code. I spent the whole time out of my comfort zone, on two very disparate pieces, and it was great. Here was an environment that required me to do nothing else but pick up those technical skills, in a very focused time period, with tangible results if I did. Much more effective than all those times I'd think, "hmm maybe I'll play around with jQuery more" and never did.

To go back to the running analogy, good software development is like running a marathon. It takes time and discipline, not preparing effectively usually means you'll end up going slower or being injured, and it's all about a steady incremental process that builds up into something great. But sometimes it just feels good to toss out your planned 20 mile run for the day, and just run out your front door and sprint around the block as hard as you can for 10 minutes, pushing yourself in a different way and learning something about your skills or capabilities that you never would otherwise.

I liked the ladder analogy but I feel like this is basically every startup's experience. You climb up the ladders, invalidate assumptions when you realize what's too short, and identify traits that make some ladders better than others. And then at the end there usually is a big honking ladder than you realize is your best bet of trudging up and getting to 'the top.' If you can make the ladder exploration process one which you earn actual money during this time, this makes it a lot easier.

The OP mentioned 'founder-startup' fit, but I wonder what kind of startup trajectory they were expecting. Nothing is formulaic about a startup, but it sounded like they had close to the standard success case as possible. They launched a product, they got some customers, they got information from those customers, they realized future growth would require a pivot in their product but that growth could easily dwarf what they had done before, and... well, that sounded like a lot of work and they punted.

The Spaciety team launched a product, got customers, got revenue, and had a seemingly clear path to more growth via investment and product enhancements/pivots, so despite shutting down I would actually consider them a success. But I finished reading this and was mostly left wondering what trajectory the OP and his founders were looking for? Very few startups had a story like, "well we put in a lot of time to launch the product, got some customers, so now we just kind of hang out and let it run itself and we probably have a 50% chance to sell for like $3 million."

The OP talks about founder-startup fit, but were they a bad fit for Spaciety or a bad fit for starting a startup in general?

Why You Should Hire More Developers: Because it's easier to convince the company's executives to do that than fix the systemic issues that are truly eating up software engineer bandwidth.

Let's assume this company has nobody with a true technology background at its leadership level, because if it did it you wouldn't have this mess to begin with. That means it's basically never an option to say, "can we stop working on business projects for two weeks so we can fix problems with our infrastructure that will make us more efficient later on."

Suggesting something like that never works because:

-- The idea of halting "forward progress" on "revenue-driving initiatives" is anathema to any executive. I've once worked on projects where the conversation with my manager has gone like this:

"[Executive] wants us to make progress on the SuperProfitGenerator Widget this week."

"On top of everything else? That's a HUGE project! How could we finish it this week?"

"She doesn't want it to b finished, she just wants forward progress."

"What's the definition of forward progress?"

"Well she just wants to know we're working on it and we're closer to finish than we were at the beginning."

"But I'm not supposed to have anything functional or anything, just 'forward progress.'"

"Yes."

"By what metrics? Lines of code? If I tell her I wrote 10,000 lines of code for the SuperProfitGenerator Widget, that will make her happy?"

"Yes."

"Wow. Okay. Um, yeah, we can squeeze that in."

[proceeds to create SuperProfitGenerator.pm class and copy-paste 10000 lines of Wikipedia into it wrapped in a "print" statement]

-- It's incredibly hard to quantify the actual efficiency gains and business people basically just assume engineers are lying anyway. Unfortunately I've seen this sort of Catch-22 play out -- it seems like the business will relent, but they want to try and quantify the efficient gains. The engineers give incredibly optimistic answers because a) we're typically terrible at estimating to begin with b) the rosier we can paint the picture, the more likely they'll finally buy-in. Unfortunately then it's very hard to deliver on those efficiency gains, and even if you do deliver, it's hard to make non-engineers realize the impact. Everyone realizes when an extra $50,000 is in the bank account. Not everyone realizes that 5 engineers have each saved 10 hours, even though an extra 50 hours of productivity over a year is easily worth more than $50,000.

-- Even if they do agree to let engineers start working on systemic/infrastructure problems, it's typically the first thing that gets prioritized. Some client will come in talking about some deal that could be worth some non-zero amount of dollars but requires additonal engineering work. The executives sit around looking at the current priorities and someone says, "It looks like the top priority right now is 'Data Model Refactor,' whatever the fuck that is. What the fuck is that? Oh it's something about database the engineers wanted to do? Fuck that, make them work on this instead."

So what can you do? If you have the option of fighting to get technical debt and infrastructure issues addressed, or just hiring more, than in an envirnoment like this it's almost always the better move to hire more. Hiring someone for a later project does make it later, but the OP is talking about a systemic overall inefficiency. It's very possible the new hire will come in and gum up the works for awhile during his ramping up phase, but on a long enough timeline they will eventually out-produce the overhead. It's politically easier to bring on someone new, deal with the productivity hit, and then have them start addressing the systemic technical issues.

Although the real answer to "what can you do?" is to not work at these kinds of companies to begin with. Companies with leadership that has true technology backgrounds don't allow these kinds of situations to arise to begin with, and if they do it's very easy for them to understand the cost-benefit analysis of dealing with them. This isn't the case at your typical organization led by a bunch of MBA idiots, unfortunately.

This article is mostly just lazy hypotheticals, but I was surprised that the author thought, "the sexual predator moral panic kicked in in 2005." I'm not LGBT, but I was pretty much 'not cool' for most of high school, and I spent a lot of 9th and 10th grade hanging out in this sci-fi/fantasy collaborative writing forum on AOL (yep, that's how 'not cool' I was), so this was like '97 and '98. Eventually I did end up meeting with two of them, a very nice couple who went to a college near me at the time, and had a fun time.

And then I told my parents I had met them through the internet, and my mom flipped her shit because all she reads about the internet is how everyone the hangs out in an AOL chat room ends up getting raped and murdered, or something.

So 'stranger danger' seems like it's been around since it became mainstream for minors to use the internet, but I would have expected it to dissipate with time, much like people used to be generally sketched out by online dating, but I don't know a single person who hasn't tried it today. Then again, as other commenters have indicated, there is pretty much no factual evidence presented here one way or another.

It's pretty hard to start a startup while you have full-time employment you're relatively happy with, both because of physical time constraints and reconciling the risk mentally.

In the past I felt exactly like these guys did: apply for incubators, which will provide both validation and financing, which makes a transition a lot less painful. It's one thing to tell your wife, "yeah so I quit my $125,000 job to work with Joe on our startup, which is really just a bunch of unreleased code at this point" as opposed to, "yeah so I quit my $150,000 to work with Joe on our startup, but we're in YC, which is like Harvard for startups, and we're getting over $150,000 in funding, and like half these companies raise venture capital really quickly after the program." Hell, it's a lot easier to tell yourself that.

A few months ago I wrote a post about my experience interviewing at YC and getting rejected, and I mentioned how we didn't continue working on our idea, and a lot of people asked me why. And the most honest answer I could give was, "I felt it was too big of a risk to take off my golden handcuffs without Paul Graham's approval," which sounds kind of absurd but is the most plain explanation I can give.

Well it's been over a year since then and I've realized two main problems with that way of thinking. 1) All an incubator can really do is amplify your ability to conceive of ideas and execute well on them. But if you can do both of those things well anyway, then you'll be successful regardless of acceptance or not. 2) If you refuse to embark on starting a startup without getting accepted into an incubator, then you're limiting yourself to "incubator-friendly" ideas, which is generally something that is consumer-facing and disruptive in some theoretically huge market (or eventual market) (e.g. AirBnb, Dropbox) or is a tool/platform that can improve the startup ecosystem of tools and platforms (which it seems like Keen.io is, if I understand their value prop on their home page correctly).

So congrats to the Keen.io for getting into TechStars, and I'm sure their product will be great, and they'll go on to be successful without having to sacrifice much more than going out to dinner a little less and downgrading their Netflix subscription. But it's very possible they were going to be successful anyway.

A lot of commenters have talked about the pros of this routine, and there are many. Few interruptions, working while your mind is fresh, working within a regimen, etc.

However, if you don't have an equivalent amount of discipline on at night to get enough rest, you will quickly burn yourself out. I did this routine for a lot of the second half of 2011, and since I'm a night owl by nature (going to bed at 12 midnight is 'earlyish' for me), the lack of sleep quickly caught up with me. My project was actually getting some traction though, so I basically spent about four months in a sleep-deprived haze and consuming about 400 mg of caffeine a day just to function.

So I guess what I'm trying to say is, if you're like me and you go to bed at 1AM, wake up at 9AM, and go into work at 10AM (a very common engineer schedule), then it's not just a case of setting of your alarm clock but really adjusting your lifestyle so you're not fundamentally sleep-depriving yourself.

You can't be a software engineer for long without working in some shitty environments filled with TPS reports, dysfunctional management, and clueless executives. It's especially discouraging when you're formerly thriving company starts devolving into this said mess, usually when it fails to manage its growth appropriately ("production went down! no more production logins for anyone except our horribly understaffed sysadmin staff!") or when its core product starts showing its age ("we're going to pivot! to high growth markets! best in class! jack dorsey! jack dorsey!")

Not all of us handle this well, and I don't know about everyone else, but I have at least one job in my past that I left with some burned bridges. The idea of interviewing for a job and having my potential new employer calling the Bill Lumbergh-equivalent whom I eventually lost my shit about and publicly chewed out for being a moron, for an opinion about me, literally puts me in a cold sweat.

So this article would worry me, but I've seen it in practice a few times, since the Los Angeles tech scene is small enough that a lot of people have at least one stint at a small set of companies (e.g. Yahoo, MySpace, PriceGrabber, Citygrid, etc). Usually it's not quite so deliberate as the article paints of stalking mutual connections on LinkedIn. The typical scenario is someone on another engineering team asking, "hey I'm interviewing X, did you work with him when you were at Y company?" and I'll say, "yeah, he was really badass" or some equivalent. Even if I don't have a great opinion of him, it's usually something like, "Well I think he got let go when they did layoffs in 2009, but his manager was a dick so who knows."

Software engineering one of the few meritocracies left. If your quality of your work is good and you're respected by your peers, then Bill Lumbergh's opinion of you probably doesn't matter. And if it does, it's probably not a place you want to work at anyway.

I turn 30 in 5 months and can completely identify with how you've felt. I too have the dozens of domain names for long-abandoned web applications for some idea that I thought was a radical spike of insight at the time.

It's a vicious cycle. I get the idea. I register the domain name, already imagining a brilliant fully-featured yet astonishingly-easy-to-use product. I start cranking out code. But it takes some time. I realized some problems I thought were easy are harder. That takes more time. I realize a certain problem is exceptionally hard and will take me longer than I thought, so I hack together something that works for now. I realize yet another problem will take me longer than I thought, and a few weeks pass and I begin to feel my web application is just a series of hacks. If we're using the art analogy, rather than the beautiful and crisp design I envisioned, my canvas is filled with ugly smears and smudges that doesn't look anything like what's in my mind.

And it's always a lot easier to just throw out the canvas and start something new, than to tediously work out improving those smears and smudges.

So, perhaps one hopeful anecdote I can share: earlier this year I did start a project that I've finally been able to focus on. The only difference with this one vs. the others is that I saw a tangible return relatively early on. Two months after I worked on it, I made $72. That's basically a laughable number, except it's the first tangible return on the dozens of web applications I've started and abandoned for the past 5 years. From then on, there's been a mostly-positive correlation between "hours put into project" and "dollars earned," which has completely shifted my mentality.

I've begun to take pride in those smears and smudges, knowing I'm already succeeding to some degree and it could be especially rewarding if I continue. I have no idea if this would work for you, or anyone else, but like others have said, this is a process. Everyone designs and creates at their own pace, and age seemed pretty meaningless to me. In fact it's now that I'm older, instead of 5 years ago, that I can begin to appreciate my limitations and have the patience to work with them, instead of ignoring the fact that they exist.

And above all, be proud that in a world where many are content to maintain and manage (literally and figuratively), you have the desire and the ability to create and produce. Best of luck.

larrys -- I'm in a similar situation and the domain brokers I've talked to have all been really sleazy. I would love to an HNer experienced in this field. I'd reach out to you privately but unfortunately your HN profile and even some light Google stalking didn't yield much as far as your contact info. So if you could contact me that would be great as well.

nate.hashem@gmail.com

I think the reason why we want to be startup founders is because it offers optimal balance of "direct implementation" vs. "impact."

At a certain scale, it's impossible to directly implement anything anymore. You can have tremendous impact but the more layers in between what's in your head and what's produced can only increase. Bill Gates wrote code that shipping in Microsoft products until the late 1980s[0]. At a certain point, he had to trade off having a bigger and bigger impact by managing the implementers instead of implementing himself.

Except somewhere along the line when you become the guy managing ten engineering departments with ten people each that help ten people write code, then you're not doing anything anymore. You're just enabling people to do things. And it becomes more and more likely they may do things in a way that's not in your head. So you trade implementation for impact, but then eventually the impact you get may not be that impactful to you because it's no longer what you did but what other people did.

In a startup, you have the best of both worlds. Impact and implementation. Eventually you fail because you didn't make enough of an impact, or you stop implementing because it's impossible for you to scale with the impact you're making. But I imagine the ride to that point is extremely fulfilling.

[0] http://www.microsoft.com/presspass/exec/billg/speeches/1997/...

$144.00 $144.00 $14.14 $10.82 $60.00

Wow. This is such a great post, and sums up exactly why every implementation of "Agile" I've seen at previous employers have been completely dysfunctional.

So there's an engineering team and they have a project manager. The post-its and standups and storyboards seem a little weird at first to the engineering team, but they go along with it. It's rarely perfect in the first iteration but they can see how doing this makes them more productive, and it beats getting a bunch of confused requirements from confused business owners, or working off cumbersome and inflexible product requirement documents. And it doesn't ask them to change much in the ways they're already communicating.

The problem is the project manager needs a way to provide "remote views" that the OP mentioned. The CEO needs to know where the implementation hours are being spent. The finance team wants to know which projects they can capitalize. And so forth. It is part of the project manager's responsibility to provide this.

This is where tools can be great. Enter in some data, enter in the stories and tasks and points and hours and projects and generate a dozen charts and graphs with the push of a button. Cool.

The problem is if the project manager doesn't manage this themselves, if they don't do the tedious task of entering in this information themselves, then it's going to be a mess. Because like the OP said, engineers aren't going to update the tool. They want to do work and if the work status needs to be updated to reflect their progress, that should just automatically happen. If they have to manage the updating, then you immediately have a point of failure because the engineer is never going to do this. Why? Because it's pointless. He's working on projects. He's cranking out code. He already has a dozen windows open on his desktop at all times to text editors, terminal shells, documentation on the web, documentation in PDFs. He already communicates to his peers via IM, email, in person, using version control, or even moving post-its on a storyboard. He is already passively indicating his status a dozen times a day. Why does he need to actively manage his status in some tool that has zero value to him or anyone he works with?

But the project manager implores, "just update your hours, guys, it only takes a little bit of time each day. We really want to maintain an accurate burndown chart."

If only it were so simple. Because beyond being completely inconvenient, the tool doesn't even use the same units of measure that he does! "Hours per story?" Does that count the hours brainstorming the solution? The hours actually typing in code? The hours working with the sysadmins to deploy the code? The hours (well, hopefully minutes) spent thinking about the project while taking a dump? If the story is closely related to another one that he basically worked on both at the same time, should he combine his hours and divide by two? And burndown chart? Does the burndown chart mean anything to him? Does it help or improve his life in anyway? We thought this project was going to take a week, but when we started getting into the implementation we realized there's huge hurdle X and now it's going to take two weeks. There's your damn burndown chart.

So the engineer hears, "just wax and shave your balls with vaseline, guys, it only takes a little bit of time each day." Because waxing and shaving his balls seems just as pointless as updating the tool. And even if it only takes a few minutes to wax and shave your balls, it's awkward enough that you will get really frustrated really quickly if this needs to become part of your workflow.

If the project manager wants to the use the tool because of the convenience and power of generating reporting charts and graphs to external teams, then good for them. But if they're going to ask the engineers to update it themselves, then they should be prepared for that to be as successful as if they asked them to shave their balls, because that is literally what they are doing.

A couple years ago, when I was at a previous employer, I was lamenting the typical corporate frustrations to a friend. The executives seemed to have a new "strategy" every quarter. All our projects had unrealistically given deadlines. Even when we successfully released a new product, it was basically DOA, because they were never things we would use ourselves. It was basically impossible to pivot our aging flagship product, because it has grown so complex that it was impossible to get any more incremental gains without a huge commitment in resources. At least once a month I'd be asked, "Well can we make this change to the product quickly?" and I would always say, "No. There are no quick changes anymore. You can either commit the staff to getting the product back into a state where we can do quick changes again (ie. refactoring some of it), or you can just put the product in maintenance mode and have the staff do something else." And yet no matter how many times I explained why, using as many MBA-friendly concepts and analogies as possible, they never understood.

My friend asked if any of the executives and managers had an engineering background, and I literally laughed out loud. Of course they didn't. If they did, they would have understood concepts in this article. Instead they were exactly like that political douchebag in The Wire video.

One of my greatest hopes for the current proliferation of startups is that some of the technical talent there actually does end up as leaders corporate America. I see the fundamental problem of corporations led by execs with the classic MBA-educated, McKinsey/Bain-trained background is they've never created or produced a damn thing in their lives, and just fundamentally don't understand why their decisions are so dysfunctional.

These articles frustrate me because nobody asks why the engineers are 'willing' to get poached. It always boils down to a few reasons:

- The company's prospects and projects are limited. Shopping comparison was cool in 2003, but it's 2011, and you have an aging flagship product with limited growth and a bunch of half-assed initiatives that never go anywhere because there's too much red tape to actually produce code and the executives are too busy getting fired every six months have any consistency with strategy.

But if you're getting tech talent "poached" in that case, you're probably getting all your talent poached, so let's talk about the other scenario.

- The engineer's prospects are limited. So few technology companies have any sort of individual contributor advancement path. A star performing sales guy goes from junior sales associate, sales associate, senior sales associate, junior manager, senior manager, etc every 6-12 months, with commissions and bonuses for strong performance.

The star engineer goes from "software engineer" to "senior software engineer" after like, 3-5 years, and then what? Either you figure out a way to get kicked into some sort of manager role or you just kind of hang around getting a pat on the back and a 6% raise every year until some company swoops in and "poaches" you with a 20% raise, which naturally seems astronomical by perspective.

Almost every manager I've had, I've had some conversation like this: "You have to give Joe a raise, and a BIG one. I know he started here out of college, but he's been here 3 years now. Because of his talent and domain expertise, he is easily more productive than any theoretical 'senior engineer' we could hire. Even if he's relatively happy, if you don't give him a raise, it's going to be way too easy for some recruiter to throw out salary numbers that will at least pique his interest."

And instead of bumping Joe's pay by 30% (which would still probably be less than market rates), he gets "poached," and now we have to hire some "senior engineer" at 200% the salary who tries to convince us to rewrite everything in Java for six months until he gets fired.

I'm getting increasingly convinced that AdWords is basically a scam. I worked on SEM optimization tools for two companies in the mid-2000s and ROI was great. Then ROI started to erode as the years passed as other players in our vertical entered our space, and as far we could tell, they were either a) just spending to make a huge brand play or b) had some way to monetize 150% than us because their CPCs were literally 150% higher.

My theory is that since SEM is often a separate unit from every other marketing organization in a company, this is what happens: The SEM team sets up an AdWords campaign, get great ROI on terms that contain their company's name or whatever, and crappy ROI on everything else. But the campaigns as a whole are ROI-positive, and because they're all being evaluated on that, no one will ever suggest, "hey, I know our company name is Joe's Widgets and we get great ROI on keywords like 'joes widgets,' but maybe we shouldn't buy that keyword at all because anyone searching for that will also see us as the #1 organic Google result." Because if the SEM team did that then their campaigns would no longer be ROI positive even if the company as a whole would benefit, and working for unprofitable departments is generally not good for your career.

Now I'm working at a company that's a major AdSense publisher and at least once a quarter something happens where we get a huge clawback for "quality issues we can't disclose," or we have to change our implementation, or whatever. It's just totally infuriating and I've realized there must be a lot of people like me who have basically spent their entire career being Google's bitch on the traffic acquisition side or monetization side.

I'm not so worried about monetization, as there is more than one way to make money from the internet besides AdSense. But as far as AdWords, I'm wondering if there's going to finally be some sort of tipping point where the mid-sized companies that have gotten squeezed out of AdWords find some other paid traffic provider that isn't infested by a) huge companies just making stupid brand players and b) small players blowing their $100 credit like what is described by the OP.

What would such a traffic provider look like? They have to be search PPC (again, lots of options for non-search paid traffic), they have to have enough volume, they have to have the technology to combat things like click fraud, and they have to be called something else besides Bing/Yahoo (which unfortunately have all the problems Google does, except less volume and even more terrible advertiser tools/APIs).

You're sitting in a meeting to talk about strategy next quarter. Ideas are flying. People are talking over each other. Every so often someone scrawls something on a whiteboard. Then they start talking about dates and "quick wins." Estimates get thrown out, which inspires another furious rush of discussion.

You keep trying to interject. You lost two engineers a month ago. Another one has put in his notice. You hired a bright kid a week ago, but he's going to need time to ramp up. You keep trying to say that hiring needs to be the focus of any new strategy, because nothing's getting done if you don't have the engineers to do it. You keep trying to raise this point and get the group to talk about how you can redouble your recruiting efforts, but everybody wants to talk about "establishing social media channels" and "improving our performance marketing network."

So finally, you sigh, and raising your voices a couple notches, you say:

"There is no way we're doing to do ANY OF THIS SHIT with our current staff."

The room quiets down. All heads turn to you.

Then the CEO says, "All right, let's talk about recruiting."

Well, just a few counterpoints here:

- I gave font size as very easy example, and there are dozens of products that make that very easy. But a lot of our testing ends up being very heavily backend-oriented (e.g. "let's try this new optimization engine combined with this optimization engine"). So any third party tools probably won't be plug and play unless we made some fundamental changes to our web applications.

- And I have quantified making those changes long before the layoffs (although I had another in-house solution in mind, not one that used third-party tools), because even if 1% of engineering time is spent executing scripts like robots, that's 1% that could be better deployed into a profit center for the company. The problem is, like I'm sure many engineers understand, is dealing with executives who don't quite grok the technical limitations of the current system, and who have a hard time prioritizing anything that doesn't directly lead to more money in the bank account.

- And this is my main point... so we had layoffs, and ended up coming to a defacto more efficient solution, which would be okay if me or anyone else involved in this solution was compensated accordingly. Instead it's executives that will get lauded for cutting costs, even though the current solution now introduced a high risk of impacting our ability to actually execute on the aforementioned initiatives that would lead to directly more revenue.

- So basically, what I'm most frustrated about, is this: I had a proposal that would have improved an inefficient process. That proposal got ignored, then we had layoffs, then we were forced to improve on that inefficiency in a way that wasn't that much more efficient. If we ultimately get this all to work, the executives get bonuses for increasing profit by lowering headcount. If it doesn't, they get cut loose with what I assume is some generous compensation package.

I'm not trying to just rattle some populist chains here or complain about "the 1%." My point is, it's not the actual elimination of jobs and creation of 'shadow work' that is a problem, but the context of which is eliminated. In most cases it sucks for the people whose jobs got eliminated, and it sucks for the people who now have do the shadow work because they're not seeing the rewards of the new efficiency (e.g. lower prices at the grocery store). Instead, some layer of people highly detached from the process typically gain the most benefits.

The problem with 'Shadow Work' is that it rarely benefits the people who have to actually do the work.

My company has a homegrown A-B testing platform. Without getting too far into the technical details, the process typically occurred as follows: A business unit would suggest a performance increasing hypothesis to the statistical analyst ("let's change the font size from 12 to 14, I bet that'll increase conversions"), who would clarify the hypothesis into a statistically correct terms ("let's set 1% of our traffic to size 14 font and segment the resulting revenue this way") and submit a ticket to the engineering team, who would set up the test using XML, then ran a script that would convert that XML into MySQL insert statements, which populated a table that the web application would read from.

Then we had layoffs and engineers were canned. To mitigate some of the work for the engineering team's now reduced staff, I gave all the analysts the necessary permissions to set up and execute the XML -> MySQL translation themselves. On the one hand, they appreciate the direct control. On the other hand, they've fucked up production more than once with malformed XML and the like, which is something they never had to worry about before, which in turn has caused huge headaches for my team.

Is this 'shadow work'? All I know is that my company used to employ more people, and both engineers and analysts were happier. Now nobody is happy, even if the productivity per person is higher, except maybe our executives who have squeezed out more productivity out of fewer employees.

Hmm, maybe I should see what those OWS guys are babbling about after all.

What really struck home for me was Steve's line, "I hate... plussing" because I actually think his entries like this one are a great niche for Google Plus -- it's basically a built-in blogging platform/RSS reader. Facebook and Twitter are pretty bad platforms for posting 5 paragraphs (or 25 paragraphs, in Steve's case) worth of thoughts, but Google Plus works pretty well. It has all the sharing/social goodness of those platforms without the overhead of having to create your own blog and tell people about it.

So I thought about a web application that would basically provide a wrapper to post blog-esque entries on Google Plus, and sure enough I looked up the API, and like Steve, you pretty much just get the Stalker Method[0]. Not a POST method to be found.

Then it made me recall an earlier life where I worked on an SEM optimization platform, and the most common thing we heard from our Google Rep was, "oh, um, yeah, doing that is not available in our API."

Short of a directive from Larry and Sergey and the willingness to follow through for the 3-5 years it took Amazon to reap dividends, is there anything Google can do?

[0] https://developers.google.com/+/api/

(getting a Page Not Found error now... Google Cache: http://webcache.googleusercontent.com/search?q=cache:qu58iS1...)

This is the problem. The problem is you're a developer at your mid-sized company, working directly with sales or analytics or whatever team you support, but you notice your projects aren't coming out quite... right. There's always some important interface feature that is missing, for example. "What if I want to bulk delete the list?" the sales team asks you, and you had no idea they wanted to delete anything from the list, let alone in bulk.

"It would be so nice," everyone starts to think, "if we had a product manager that actually had time to think about this stuff and manage communication, requirements, and expectation."

So you hire one.

He has no prior expertise in your industry vertical and he has no programming background whatsoever.

Things are immediately rocky. Rather than manage expectations, he seems to inflate them. He's constantly trying to cram every new project and feature request down your throat. Any estimate you give him is questioned. While he has no programming background, he knows enough about tech to suggest terrible alternatives that will save a couple days of development time at the cost of huge technical debt. Meanwhile, any suggestions you have fall on deaf ears. You notice areas where the sales team is doing things really manually and suggest enhancements, but he's not being judged on how well he listens to engineers.

Before long you miss interacting with the sales team directly, because even though they asked for completely pointless things that were technically impossible anyway, at least they listened to you when you explained why it was pointless and impossible.

So you grit your teeth and bear it, and wait until the company has a down quarter and needs to let people go, because product managers are almost always on that list.

---

I've worked with several product managers in my career, and the easiest heuristic for how effective they truly were and how much engineers liked working with them was whether they had a technical background or not. Being a good software product manager is hard. You have to understand the cost of technical debt. You have to understand that engineers have good ideas too. You have to understand the tradeoffs of projects with long-term value. If you're a product manager who used to be a programmer, understanding all of the above is very obvious. If you're a product manager who was never a programmer, maybe you're Steve Jobs.

But you're probably not.

I hate ties and collared shirts in general. Any wedding or other formal event where I have to wear a suit, I'm constantly tugging at my neck and ripping off my tie within 5 seconds of getting back in my car to drive home after the event. I have no idea why Steve Jobs wore his ubiquitous turtleneck, but I'd like to think the fact that it was a lot more comfortable than a shirt and tie was one of the reasons.

Also if I'm at any sort of business or social event and someone is comes up to me and says something like: "Hey bro, I've been sitting on this great idea for a startup that I came with when I got my MBA at Oswego College, and I need a cofounder. Here, sign this NDA and I can tell you about it. Okay fine, don't sign the NDA, bro. It's called 'Fratastic.com,' it's like frat-oriented humor videos. It's gonna totally be the next youtube, it's ridiculous how much money it's gonna make, bro. I have the domain name and everything, I just need someone to actually do all the coding and I'll do the marketing, bro. How does 4% equity sound to you?"

... well, that person is almost always wearing a shirt, coat, and tie.

So why would I want to dress up beyond a t-shirt and jeans? It makes me uncomfortable, it has nothing to do with my production, technical or otherwise, and I'm less likely to be associated with the expensively educated clueless douchebag I described above.

Also, I know a lot of hackers who do go to the gym or otherwise keep active and look just fine in a t-shirt.