Engineer Driven Development

What do startups, big enterprise teams, and individual developers have in common? If left unchecked, they all tend to drift toward engineer driven development.

If you try to follow lean, or any other buzzword that focuses on building product, EDD will wreck your product and leave you with an unprofitable, unmaintable pile of garbage.

Every company inevitably runs into the need to solve a solved problem. You need monitoring? New relic. You need a web service or need to build a web app? You can probably name 15 frameworks that would do the job pretty well. You need elastic server capacity? There's EC2.

But plugging known, tested, common components together isn't fun. It's work. No one gets excited talking about how they set up rails with postgres and now they have working REST endpoints.

You know what's exciting? Writing your own web framework. It's riddled with edge cases and holes, and you can spend literally infinite time in a sandbox accounting for different use cases you don't have now but might have one day*.

* You'll never have those use cases.

But Stefan! Basecamp did it! Basecamp built Rails!

Yeah, they did. And you're not DHH. We all want to be attractive, racecar-driving open-sourcistas with danish accents, but that's not reality. We build software in the real world, and in reality, your garbage in-house web framework won't scale beyond 10 customers, requires millions of dollars a year in engineering time to maintain, and is four to ten times as inefficient to develop in than the free or marginal-cost competitor you sought to displace.

And let's not forget onboarding. If you ever plan to work with a single other person, they need to learn your bullshit in-house solutions to solved problems. Instead of instant familiarity with your new relic account or rails, they need to parse through your engineering masterpiece to figure out how to change a line of text on a webpage.

This is just the literal cost of building solutions to solved problems instead of using open-source tools or buying the right tools for the job. Opportunity cost is much higher.

What did you lose by spending a year building a replacement to a known solution?

You lost a year of product development. 

If you're small, this can be financially disastrous. If you're big, you can only eat your own crap so many times before you're so slow and bloated that you can't compete.

The engineers had really good reasons for building their own dog-crap. Or at least you think they had good reasons. At the very least they were persuasive. Who could have known that we would have lost so much time building the product?

So who's responsible? The engineers? Sure, but blaming them won't get back all that money you lost to competitors.

Everyone is responsible for stopping EDD: technical founders, managers, testers, developers.

Everyone.

App Store approval after 4 rejections

A few weeks ago, a small app I created to help with Pokemon battles was rejected from the app store. Four rejections later, I'm in the app store. Here's the story.

If you play Pokémon online, you quickly realize that most everyone online is serious business. A misplay will cost you the game. So I created the app.

Submission 1: Pokemon Types

Rejection: 10.6 

10.6: Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected

When I submitted the app, there was no other website, app, or experience that provided that interface. So I pushed back. Then I got this:

22.2: Apps that contain false, fraudulent or misleading representations will be rejected

Fine. Despite the myriad of "Pokémon" named apps on the store, I figured it was reasonable to change the name and re-submit the app. 

Submission 2: Quick Attack

Rejection: 10.6

Okay. Maybe someone at app review just didn't like the app. As I continued battling, I realized it would also be useful to see a base stat breakdown of each pokémon. Should I send out my special sweeper or my physical sweeper? If we're both geared and specced for speed, who will move first if I attack now?

So I expanded the app, hoping to get past the dreaded, subjective 10.6 rejection. At the same time, another app was approved to the app store with a nearly identical interface, flaunting the word "Pokémon" all over the app and in the app name. Fuck me.

Submission 3: Quick Attack

Rejection: 10.6

Wat. Since installing the app on my phone, it has been my most used app, aside from my podcast client, maybe. I know there's value, so I appeal.

Rejection: 22.2

This time, I get some more information. They tell me that the app icon is at issue, despite never mentioning it before and just pasting the fucking manual at me. RTFM has never felt more depressing. But an app icon is fixable. I remove any reference to anything and try one more time.

Submission 4: Quick Attack

Is the icon awful? Sure. I intentionally made the icon as bland and lifeless as possible to avoid any potential conflict with any trademark of any product in the world. I may accidentally bear resemblance to some nation's flag. I wouldn't know. I just wanted a quick submission.

Rejection: 10.6 and 22.2

Ooh! A double whammy! Except this time, I know for damned sure I've addressed all the issues that app review had with the app. In one last attempt, I appeal again. This afternoon, I get this:

Huzzah. Ready for Sale! It took several weeks, but I finally did it. I fought the law, and I won. 

Do I feel good? Not really. A simple app was delayed several weeks without a whole lot of feedback in the rejections. Why is app review time 7-10 days? I hear Apple is full with profit, literally brimming with cash and little to do with it. Apps are the cornerstone of why iOS is so successful. You think Apple would give a fuck.

With a tight feedback loop, I could have handled these 4 rejections in under a week. Does it really take 8 days to review an app with two views? For a new app or product, iteration is everything, and Apple makes it really, really difficult. I wish it didn't.

If you like Pokémon, go download Quick Attack from the app store. I hear your chance of finding a shiny improves if you leave a tip.

10 questions to ask your potential employer

The interview is all too often driven by the employer. Can you handle this workload? What are your strengths and weaknesses? How do you feel about this aspect of the business?

But at the end of the interview, you do not know enough to know if you will actually love and enjoy the work. How many developers or designers do you know who have worked at a place for less than a year? Less than 9 months? I bet more than a few.

Here's some questions you should ask before committing a significant portion of your life to a company.

1.) What's the process like? How do you build software? Do you describe yourself as "lean", "agile", or "scrum"?

This can make or break a position. If the work culture hasn't been somewhat formalized, you might be entering a position where your main job is managing the chaos. If a company thinks they're doing "lean" or "agile", this might mean you're walking into a formalized reasonable process, or it could mean that you spend half your time in meetings with decks of cards arbitrarily assigning cost to problems. The most important thing is that someone, at some time, has consciously decided how work is developed at the company, and it makes sense. Be cautious of too many buzz words.

2.) How do designers work with developers?

Do they even have designers at all? Is design a top-down throw-mockups-over-the-wall situation, or is there any room for collaboration and iteration? Developers acting as their own agents of design almost certainly means that design isn't important to the company, and most of the products probably suck. If you have a really good product person with design sense, you might get lucky here, but more often than not everyone is shooting from the hip and it will show in the products you build.

3.) What's the state of automated testing? Continuous integration?

Automated testing can be awesome. I use automated unit/integration/functional (where viable) tests for any products I build, and it shapes the interfaces and makes code maintainable long term. But you can hit extremists on either end of the spectrum.

1. We don't have tests.
   
   Get out. Your about to slam into a million line code base where only the original authors have a chance of making changes and not breaking the product. And you'll be blamed for the breakage.
2. We have 100% test coverage.
   
   Bullshit. Or most of your tests are asserting private method calls with mocks, stubs, and other 0-value tools that were invented to achieve 100% test coverage. Trying to change anything in the application will either break the entire test suite or break none of the test suite. Either way is dangerous. And you'll be blamed for the breakage.

4.) What *exactly* will I be working on? What's the tech stack?

Job postings are notorious for lying or on job postings to attract developers. Many times, there's one developer in the company who loves pet-technology-X, so he lists it on the job application, but it doesn't relate to the job at all. For example:

"Needs experience in rails, iOS development, HTML5, node..., and Perl experience is preferred."

What this really means:

"Most of what you do will be maintaining a 2 million line perl server application. I want to rewrite everything in rails and I like iOS, but we'll never actually do this."

5.) How big are the teams? How big will my team be? 

You can't move Mount Fuji, no matter how clever you are. If team sizes are small, and there aren't many teams, there's a very good chance you can make rational arguments and fix problems with the development process or with the team. In a large organization, you're going to crash against individuals in positions of power and change structures optimized to preventing change. Change is scary, and we've been kind of successful with the current process and 100/200/1000 people! Why would we need to change anything? You're the outlier, and you're the problem. In a smaller team, you can't be an outlier. That's math.

6.) Is there any allowance for remote work?

You may not even want to work remotely, or work remotely a significant percentage of the time. Still ask this question.

Why? This is a direct indicator of whether or not the company is looking for work output or warm bodies in chairs. Do you really want to work somewhere where the employee spending 10 hours a day in the office (mostly on reddit and in useless meetings) is valued above the employee producing 2-10x their output? Fuck no. Certain industries have strange legal reasons for requiring everyone work on-site, so that's one possible excuse for disallowing remote work, but by and large, "everyone needs to be in the office" === "we care more about warm bodies than results."

7.) Are there core business hours?

If all aspects of the business are perfect, but there's no room for you to pick up your kids, or work out, or attend your weekly book club, is the job going to work for you? Probably not. If you're dealing with customers, it's not unreasonable to need to cover a window of time, but it's still possible to be flexible with "core hours". A strict adherence to core hours might mean that most business processes are synchronous versus asynchronous, which will strictly bottleneck your ability to get shit done. Pry a bit here, and figure out exactly why there are core hours, and what it means about the company.

8.) Why are you hiring? Is this a new product? Scaling? Did someone recently quit?

A company in the midst of churn is a telling indicator that something is wrong with the company. It could mean that compensation is poor, or work life balance is off, or the work culture is toxic, etc. If someone left, find out why. If the company is scaling, you may be joining a 100 person company you believed to be a 20 person company.

9.) What's the coolest thing you've built here, personally?

I like to build products that ship. Some companies don't. Find out what the last successful project your interviewer worked on was, and when it made it into customer hands. This tells you whether the company delivers in small increments, or allocates huge budgets to failed projects. How many projects have you worked on that never made it into customer hands, or failed as soon as it was launched? How did you feel when that project ended? 

Asking what the "coolest" thing the interviewer has built will tell you if the employees take pride in the work they're doing. A software developer or designer will gush on a dime if they've built something even mildly interesting that even a single customer loved. This is what you want. 

Beware of "I built an internal tool that..." or "I built a flux capaciting tool that..." or "I rewrote an open source tool because...". Some developers like to jerk off to rebuilding the wheel and wasting business money on projects that strictly aren't required or useful to the business as a whole. Like I said, I like to build products. If you feel like you needed to rewrite the compiler, you're probably awful, and almost certainly wrong.

10.) What do you wish you had known about the company before working here? What's the worst part of this job?

All companies have problems. Stop tricking yourself into believing Canaan exists; it doesn't.

At a good company, your interviewer won't be afraid to be honest and divulge the shit. When someone isn't afraid to call out the shit, the shit can be fixed and changed. No relationship, company, or product is perfect. How you manage issues defines whether coming to work will be a slog or will invigorate you. "I have to deal with X today. Fuck my life." or "I get to try and fix X today. Today is the day we fix this problem forever."

At a bad company, you're gonna get a sales pitch. "My biggest weakness is being too devoted to perfection." Here are the possibilities:

1. Your interviewer is lying to lure you to the job. They know that it's very, very costly and disruptive to switch jobs, so they figure you'll be stuck as soon as you join the company.
2. Your interviewer is afraid to be honest. You've found a culture of silence, and you'd better be ready to put your head down and ignore problems. 
3. Your interviewer has drunk the Kool-Aid. This is just as bad as lying, except they don't know that they're lying. If no one in the company sees the 80 hour a week forced overtime as a bad thing, GET OUT. You'll either get sucked into the brainwashing yourself or be forced to deal with people who cannot see that there are problems to be fixed. 

Not all companies are evil, but know what you're getting into. We only have so many years on this planet, and you don't want to waste those digging ditches with your head down.

App Review rejection 10.6: Fuck you.

• 
  
• App rejection. Sometimes it's legitimate, and then sometimes it's this:
• 
  
• 10.6: Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected

Last week, I wrote a quick app to look up the type effectiveness against Pokémon as I battled my way through Pokemon Y. It's a fun game, but there's no resource out there that quickly and cleanly answers this question:

"When I'm battling a particular pokemon, what is its type(s), and from those types what are its weaknesses and resistances?"

There are 719 Pokemon, so the odds that you can remember the types of each pokemon are roughly 0.

Here's what I made:

Is the app simple? Yes. But that's the point. Any more or less information, and the app is useless. There's a $26 Pokédex app on the app store, and it's a steaming pile of trash. You know what I don't need when doing battle challenges or playing online? Videos of pokemon making sounds.

Nintendo is really bad at making interfaces, and it shows in their app.

No website or app exists that provides this kind of ease of use lookup, but apparently that doesn't matter. And this is the same app store that approves fart apps.

I love email

It sounds strange, right? For many people, email is a giant bucket of stress that most-likely will never get processed. "I have 500 emails in my inbox. What am I going to do?"

Exactly. What ARE you going to do? You've created a system whereby you can never process your inbox, and thus it's useless to you. How can you parse the wheat from the chaff when you have fields of wheat and a only a hand tool?

Here's why I love email:

Whenever I get a odd number of minutes to process my inbox, usually in the morning, or after lunch or dinner, I defer, delete, respond, or unsubscribe to every email. I do my own customer support, so my batch can sometimes get quite large. I find that processing these emails in the morning works best as my mind spins up.

If you're keen, you'll note that I'm using GTD, and I do it with Mailbox.

For me, email is a queue that *will* be processed. I ruthlessly unsubscribe and prune anything that isn't value-relevant to me or that I can't take action on. You don't need to read every email in your company to function. Newsflash, you already don't. Your 2-week late reply to a decision that needed to be made a week ago is worthless. Stop pretending you're on top of your incompetence.

I hear constantly that people get better response from calling than from emailing, and I have to imagine that this is at least a little due to the fact that email, for most people, is a giant bucket of spam and irrelevance that's never really going to get processed.

Because my mailbox is the source of my GTD workflow for general tasks, I email myself for each task I encounter throughout the day.

Here's what I did today:

• Print shipping label for key
• List iPad on eBay

And I processed those items with the rest of my email, in time I allotted for batch processing email.

You're balking at this point, and screaming and writhing because "you just have more important email." You don't. You have email you're not prioritizing or giving proper attention, and that doesn't help anybody.

Download Mailbox, and give it a try. Email GTD will change your life.

Ruthless prioritization

When I think about how I manage work, I always draw parallels to how people manage their lives. When's the last time you were in this situation?

Chris: So, ready for lunch?

Bob: Sure, one sec. I just need to reply to this email. Should be 5 minutes.

Frank: Hey Bob, can you send me that spreadsheet when you get a chance? 

Bob: Right away.

Chris: Done with that email?

Bob: Had to stop for a sec. Give me another 5.

Angela: Bob, could you show me where I need to be looking to fix this accounting issue?

Bob: Sure thing.

All this time, Chris has been putting off starting a larger piece of work because of Bob's initial time estimate of 5 minutes. You might think that Bob is just a really busy person with a really important job, but I disagree. Bob is a mess who has no idea how to prioritize his work. He can't even get himself to lunch, let alone send an email or complete a serious task.

The problem with all of this is that Bob thinks he's being productive, when in reality he is fighting fires with no order or priority. I'm a big fan of GTD, and whether I'm working or going to lunch, I make damned sure that 

1. I'm working on the most important project for my current context, and...
2. That project takes priority and keeps getting worked before any lesser priority task.

A project, in GTD, is anything with at least two steps. I defer, delegate, or delete any project that comes along so that I can continue working on the highest priority thing. 

Food, sleep, and exercise are important. When you say "I don't have time", I hear "I'm awful at planning and waste a lot of time on Reddit".

The concept of "working through lunch" is asinine. You're not working; you're pretending you're being productive by reading email or attempting to accomplish other menial tasks while spilling food and liquids all over your $3,000 tool. You work, or you lunch. 

The next time you're in an airport, take a look at any laptop propped open at a restaurant table. Every single one of these people is exactly the same: miserable and distracted. Focus on what you're doing, and do it well.

I'm going to lunch.

Feedly is awful.

I tried to use Feedly. I really did.

But by default, the layout is a cluster fuck. Google Reader was simple by every sense of the word. There may have been advanced features, but I never used them and never had to. I don't have time to dick with all the software I use, so if the defaults aren't good, I quit. Easy.

Here's the busiest screenshot you'll see all day:

I clicked the right angle bracket. It did nothing.

And then there's this odd notion of categories that I don't entirely understand:

Okay. Maybe there's something in the preferences that will turn off all the bullshit.

Ha, no. Check this out:

That's right. There's a preference for the colors of the links. Wat.

Build a better design, and you can remove these nonsensical preferences. Yes, you will lose some customers who demand a toggle for whether or not buttons have outlines, but you don't want those customers.

So what replaces Google Reader? Check out Digg Reader. The interface seems cleaner and simpler than Google Reader. It's iteration.

Feedly had an existing product to improve, and instead it made a bad copy. Kudos to Digg for iterating forward and instead of layering on garbage.