I'd always rather work with someone who ships over someone who's technically brilliant
Lets define what ships means then. Does that mean that they are just really good at debugging so that the limited features you do have don't break? Does it mean they know how to distill exactly the use cases needed so that you don't develop more than necessary?
I can think of many ways to ship something that is incomplete, but that doesn't mean it's worth anything so I am curious about this statement.
I've known a few great starters, a few great finishers and a lot of neithers.
The starters could rapidly invent brilliant tech and get it to a prototype phase that looks beautiful on the surface, but is unshippable under the hood. When it came time to clean, polish and fill out all the annoying details, the starters got bored and distracted. They either slowed to a crawl or convinced themselves that some new invention is necessary to ship what they are supposed to be finishing.
Good finishers are actually more rare than good starters in my experience. The finishers I've known are terriblely uncomfortable at the start. Everything is too vague and open ended. They weren't terribly imaginative or inventive. But, when it came time to ship they got in gear. Here's the burn-down list. Fill in the details. Check the schedule. Get it wrapped up, put a bow on it and shove it out the door!
Some companies die before they even ship a product to customers, and actually getting your imperfect product out there in front of customers is a really important and difficult step to take, and usually results in you finding out you need to change it in significant ways you hadn't even considered.
Some companies die after they ship because they used up all their money just getting to the shipping stage and run out of time.
What you are defining is a single event. Shipping is a constant process. "ABS" always be shipping is pretty much the standard, so your definition makes no sense.
Maybe I am just crazy though because isn't that the whole point of Lean startup, MVP etc...? You ship before things are ready in the "pretotype" phase?
I'm not so sure if it's the standard? I've seen many startups that took 6-12 months to ship the first version of their product. Usually the owners had read Lean Startup but still wanted to fix that one more thing before releasing anything.
Coding something for more than half a year without any real users makes selling the idea difficult, and makes any setbacks bigger in terms of lost morale and keeping momentum.
getting the product out is one of the hardest things for a early stage startup. people who can ship will increase the possibility of the product being released .
small example :
Business guy : guys we need to send a welcome email after a user registers.
coder1: adds code in the registration controller . ( 10 mins ) done.
coder2 : I think its better to use a event system to create an event for user registration and use a spool to send the email.
coder2's "idea" might be technically better than coder1's implementation but its waste as Coder2 doesn't actually take the initiative to code ..he knows just about everything in CS and for some reason prefers not to code . And still argues that coder1's solution is not correct.
"coder1: adds code in the registration controller . ( 10 mins ) done."
And once your code accumulates enough of these 10-minute hack jobs, it becomes incomprehensible and unmaintainable, and every little change will break something. At that point, progress grinds to a halt. You'll then need someone like coder2, who has a talent for system architecture, to refactor them back to a sane state again. (I've been both coder1 and coder2, under different circumstances.)
This is a pretty good example of what does it mean to be good at shipping. Sometimes you have to acknowledge that what you are doing right now is not the best solution architecture/design/whatever wise, but it provides the best quality/cost ratio.
Of course, it shouldn't be used as an excuse for releasing simply crap solutions. Experience comes handy when it comes to deciding whether it should be improved or it is good enough and should be refactored some time later.
Well, coder1 is leveraging technical debt. You have to find a balance because that 10 minute hack will come bite you in the ass later - sometimes only days later!
I interpret the author's use of "ships" to mean "gets shit done" - which I agree 100% with. It's too easy to get seduced by the dazzling technical mind, and in my experience these folks are great on paper but have an odd way of causing nothing but chaos outside of their specific talent.
Have you been around people who own a project from start to finish and nothing but their name is on it? The most common holdup is that it's never good enough for them. I've seen start up projects that I could've done solo in a couple of months that took a small team a couple of years. The reason for things like that is usually they don't ship a product and when you don't ship you don't have feedback motivation to work on the important things (or sometimes no motivation to work on anything at all)
I've seen start up projects that I could've done solo in a couple of months that took a small team a couple of years.
Perhaps speaking to the net result of the product, you maybe could have done that in a couple months... But there is far more to building product and a company than one developer coding in a room. I highly doubt that you as an individual can create a solution that matches a good team with domain knogwledge, in fractions of the time it took them.
This makes me think of 2048 the game, where the Dev took some time to build it, released it, and in hours there were clones in the App Store. Sure anyone can reverse engineer anything. Especially web sites where you are given their code. But thinking through, debating features and functionality, truly solving a hard problem takes time.
That's precisely my point, although reading back I did a terrible job at making my point. I'm not a quick awesome rockstar or w.e. - I just know the value of getting something into users hands fast and finding out what my users think is important. With that motivation you don't sit around all day theorizing and rewriting your perfect little flawless gem and you get something out there that is always a little dirty, but continually meeting a need rather than sitting around fluffing someones ego.
Their end product took quite a few iterations because they saw things they thought were better and started over so many times. You don't do that when you are solving problems for people, you can't just throw something away so you get dirty and you solve real problems. Sure, you're not going to win internet points on hacker news for the most pornographic code base, but you're actually helping someone with your code.
Haha, you have a good point, but 2048 is a terrible example because it's one of many clones of Threes. What you said applies very well to Threes, though.
The classic example was RMS cloning the features Symbolics created. It was possible because once you have figured out what to do, doing it is just code, that is the easy part.
Have you been around people who own a project from start to finish and nothing but their name is on it?
I actually have never seen this. Everyone I have ever interacted with who was working on a project either had it in a customer's hands (so they said) or had it available on github for people to look at.
I am sure it exists, but I have never run into anyone who refuses to release their work to anyone at all. In fact it's generally the exact opposite, they can't stop telling people about it.
Lets define what ships means then. Does that mean that they are just really good at debugging so that the limited features you do have don't break? Does it mean they know how to distill exactly the use cases needed so that you don't develop more than necessary?
I can think of many ways to ship something that is incomplete, but that doesn't mean it's worth anything so I am curious about this statement.