I will launch Monday! But no... #buildingathing

I said it as if it was true, and then I thought through the reality of that.

No. I won't launch Monday. Although I believe strongly in the "ship as quickly as possible" sentiment, you still get to own your standards, and mine are not served by skipping out on two features that may make more time.

Blockers

There are two. First, I don't have password reset in place. Second, one of the key pieces of functionality is behind the rest of the site, design-wise. Yes, the site could be used at this point. And yes, I could be collecting emails or pre-orders, but I'm not.

I understand the idea of building while people are wanting, or even using something, lest you build a product that no one wants. I will discover that soon enough, but not until I can actually provide some friction. People will have a million ideas for something that's almost what they want. People will forget their passwords, guaranteed. "Enable resets" is feedback I don't need. I also don't need feedback on things I already know look like hell.

If I'm closer, I can't count on anyone to know why things don't work for them, but I'll actually need help understanding. If not from then, then from experts in areas where I'm weaker – design, probably.

Or, better yet, I'll discover features that people are screaming for. There are a few things I have in mind that were difficult but possibly not essential. Maybe those line up with what people want. I will discover that pretty quickly.

Decision by "I'm not __"

My initial statement was not "I'm shipping Monday." It was "I'm not building password resets." (BTW, yes, I know that this is a "simple" feature, but it's also the first trigger email to put in place, so that's infrastructure and design, not just adding a few paths and copying some HTML.)

Anywho, this type of decision statement has worked out well so far. I say "I'm not going to build 'whatever'" and sit with it. Sometimes, it feels ok, and then is a relief – I don't have to build it. I can actually live without whatever I decided to cut. But this time, I couldn't settle on that.

This happened one other time on the project so far. I said, "I won't have a full decommission/cancel button. They'll have to send an email." At first, this felt ok. An email isn't hard to send. That's not asking too much. But no, this would actually look too much like some shitty cancellation processes I've seen where people have to not just indicate they want to cancel, but then actually justify it. I had no plans to do anything that deceitful. I just thought that I might be able to not build that feature before launch.

But no. I'm building this with an explicit intent to be more transparent and under the job seekers' control that linkedin. I want to be everything they're not. No snitching. No empowering headhunters to send a bunch of unrequested and impertinent emails. No "users" as inventory. And no dark patterns (or anything that even resembles one). This is key to the brand. Archive/Leave anytime. Your data is your data. Found a job and want to leave? Great! Want to leave because you just want to? Sounds good. Tell your friends.

Design First-ish

As with the second blocker, while I intended to motivate as much of my work as possible with the "love letters" (hypothetical gushing emails from customers) in mind, my features did get ahead of my design.

I'm a developer much more than a designer, so designing first is tricky. And when the features have some complexity, my imagination is not as good when I can't see how things can fit together technically.

For marketing purposes, it would be ideal if I always had designed, fully and first. And maybe I could have done that, but would it be useful for marketing? What fidelity of screenshots can I use and stand-by, when I know that, for me, the design on the feature will look different (and also can be an actual product demo).

Making fake things for a product demo that won't actually work really grates on me. It's one of the more stressful parts of dev work as well ("hey, I know you're trying to ship this thing tomorrow, but we need a demo today, so I guess make two versions, and backtrack on the work for today and then build the other one, but BOTH of these things are very very important"). Those conversations are among my least favorite. But the other frustrating thing, is that building the demo (assuming a single dev) before the product blocks shipping.

So yeah, while I still believe in motivating the product by love letters, I'm a little less enthusiastic about design first (for me) once a certain point is reached. In any case, I'm grateful to the designers I've worked with in the past for having the vision that I have to be dragged into, if I get there at all.

But anyways, I'm guessing I'll have something to show in a week or less. If you're excited about that, and looking for a job, you can go to jobpika.com and pay money and use it and everything (just don't forget your password yet, or you'll have to email me for a reset).

Did I just ship? Did I bury the softest of all launches 7/8ths of the way through a blog post with no analytics on it? I guess.

Things that should be products

A couple of things have occurred to me throughout this process, tools that I wish I had over the past couple months.

Canonical Decent Design

I believe the current answer to this is material ui. It's unbelievably bulky and too tied-in with react or other frameworks when it comes to packaging.

The chic design right now fleeting and broken though. I find no "delight" in, for instance, gmail's sign in now unable to process "enter" as a selection for which email I'm going to use. The cursor hover state is broken all over the web. And holy shit is everything slow. Links have no indication of where they go to (on the bottom of a browser when hovering), and cmd-click doesn't open in a new tab. Navigation is so rigid on single page apps. And holy shit is everything slow (yes, it deserves to be said twice). Throw in content not loading, or loading after ads do their thing to figure out what you'd like to change about yourself, and then cover everything with a header, footer, and interstitial.

No, the web isn't delightful. Buttons that look like you clicked a ripple into a still pond of green water don't make up for all that other stuff. Hell no. AR is getting delightful and weird. 3D in general. Web UIs? No.

Bootstrap made every site look like Twitter, which was weird, but a relatively lightweight way to look modern without breaking so many things.

Anyways, decent design standards not built on top of so much baggage would be great.

Modular Site Configuration

It's not weird to me that we're still fighting framework wars. I expect (and actually hope) that to always go on. What's weird is that tooling for total modularity has not replaced much of that conversation.

Maybe this is the holy grail of web design, but why don't the "app builders" or "starter packs" get the same attention, or even more, than the underlying frameworks?

I honestly don't care that the site is in rails. It could be node. It could be anything else popular. It could be anything on the front-end (that doesn't go against interactions I've become accustomed to). Maybe the answer is wordpress. Maybe some of the open source starter packs are better than I give them credit for, or I didn't dig deeply enough there. Maybe glitch has cracked, or is cracking this now.

Maybe part of the problem is people like me scoffing at existing and cheap (but not free) out of the box solutions. I'm a developer, so I need to build it. Maybe that instinct isn't wrong at an individual level, but maybe collectively, as reward for our dev chauvinism, we're all missing out on a more modular and high level conversation about website construction. Maybe the myth that every site is special is what keeps us employable though.

Specific Modules

Some things actually really suck to set up. Not "I can't do them" suck, but "this is going to take a while and maybe has a long feedback loop" suck.

• Page Layout
• File Uploads
• Turnkey DNS
• Turnkey SSL
• Turnkey Email Receiving
• Turnkey Email Sending

Heroku remains amazing for its "git push" to deploy ideal. But as a dev, I feel like their plug-in infrastructure is at risk of feeling more like upselling weirdness a al godaddy in a few years.

Maybe heroku has an idea of "build-packs" or "images" that I missed, but it seems like the vendor model ignores what I actually want. I want a bundle of all the things that make the site seem grown up – Custom URLs, other DNS, email set up, payments, no 10 second delay thing, and that's pretty much it.

I guess docker and friends are meant to be the solution here. Something to keep in mind for next time I guess.

Back To Decisions

Anyways, the decision to cut a feature or not can be hard. The best way I've found is to get impulsive and decide on the option (for development, I bias the decision that's the least amount of work). Let it sit for a while and figure out if you can live with it.

Applied generally, this can work too. This food or that one? Flip a coin. Heads is salad. Tails is tacos. Heads... Ok, so did you want a salad? Are you relieved or annoyed by the coin's decision? "The coin has spoken" says the happy future salad eater. "What does a stupid coin know?" says the taco enthusiast.

I guess that's to say, go with your gut, but give your imagination something concrete to work with first.