18 ms·

I Shipped, Therefore I Am

301 points by jashkenas 6y ago

machinelabo 6y ago
I am not a fan of the term "ship", similar to "sell". It's a horrible term. It evokes the image of a frantic imprudent developer churning away at ball of mud trying to meet their shipping metrics and feature bloat targets. Does anyone feel the same? If someone told me "I sold stuff, therefore I am", it just leaves a bad impression of them for me. Build stuff with care and craftsmanship. Strive for excellence, take pride in your work and deliver, not ship.
- years3500 6y ago
  You nitpick, therefore you are not cool.
  - chuckSu 6y ago
    Comment of the week
- thitcanh 6y ago
  I am not a fan of the term “build”, similar to “deliver”. I’m more of a “manufacture” and “bring to life” kinda guy.
  - machinelabo 6y ago
    I like those better. Craft is great as well.
    - quickthrower2 6y ago
      I like “unleash”
      - TeMPOraL 6y ago
        I prefer "expose", as in "expose to radiation" - it connotes long-term suffering of the users of my work.
        quickthrower2 6y ago
        Or perhaps expose as in emperor has no clothes!
        TeMPOraL 6y ago
        My software does both!
- keiferski 6y ago
  Steve Jobs popularized the phrase “Real Artists Ship.” He was also famously obsessed with craftsmanship, especially of the parts that weren’t seen by users. https://thenextweb.com/apple/2011/10/24/steve-jobs-obsession-with-the-quality-of-the-things-unseen/ https://thenextweb.com/apple/2011/10/24/steve-jobs-obsession...
  - ValentineC 6y ago
    It's so nice to see this article, and wonder what Apple was thinking when they were deciding what material to use for the insulation on their Lightning and (old) MagSafe cables. Original Apple cables seem to suffer from the insulation flaking over time — and Genius Bars all around the world (I've tried, many times) refuse to acknowledge that it's a manufacturing defect.
- iagooar 6y ago
  You can build something that is excellent, yet if you do not ship it, it will have no impact. Shipping to me is bringing a technical feature or increment to customers' hands. It is a product, yes. You sell it, true. There is nothing wrong with that if you are solving a problem or removing a pain.
- steve_adams_86 6y ago
  I’ve always thought the term and colloquial meaning in tech arose from the need to act on delivering, otherwise one could focus on craft almost perpetually.
- SiVal 6y ago
  No, I remember what it meant. Once you put a product on a ship and watch it sail away, you can no longer tinker with it. You might not feel finished, so it takes resolve. Finished or not, when it sails away, you're done. Back when software was treated as a physical packaged good, it had to physically leave your "factory" by a certain date to qualify as a sale during the quarter, allowing it to be claimed in a quarterly income filing, which would boost the stock price and, thereby, the compensation of execs and employees. So, the sales team would sometimes have to carry an armload of shrinkwrapped boxes out the back door into the parking lot to claim a sale for that quarter. It had legally "shipped". The programmers (former high school nerds) would be desperately hanging on to the code until the last possible minute--there was always more that ought to be done--while the sales team (former high school jocks) would be forcing the programmers to "hand over that disk, now, nerd!" No courage was required by the sales team to ship. Their job was just to book the sale. In the parking lot by midnight? Hello sales bonus. But real courage (or threat) was required by the programmers, who would be forced to let go of code that could not be fixed "thru the wire" in those days, knowing that they would be blamed for every flaw that they "shipped".
  - deleted 6y ago
    [deleted]
  - machinelabo 6y ago
    Oh I remember when video games used to be shipped in that they had to finish everything. No patches later. It’s going to get burned on the ROM and off it goes sailing to their customers. Now a days, shipping to me evokes “Fuck it, ship this shitty MVP to customers because ship ship ship” and then they wonder “Gee, why didn’t my app take off?”. I understand the need to ship, but I never see anyone daring to challenge the frantic broken shitty app philosophy and maybe wondering if they built them with care, maybe... just maybe customers with actually come? Has anyone tried to go against the grain since the SEGA days? It’s high risk. Thanks for a great perspective.
    - paulryanrogers 6y ago
      As a counterpoint, I've a janky product that I've soft launched. It's definitely a rough beta. But because of churn on the underlying platforms it'd be a constant, full time battle to polish out all bugs. Even then some quirks may never be fixed because web extensions aren't technically meant to allow interrupting all means of browser navigation. And for me it's all a (sometimes not so) fun little side project. If I had never launched at all then it's possible no one would ever get the benefit of my unique feature. There are similar competitors which I'd rather just buy and use, yet they don't have the one killer feature I wanted.
- melomal 6y ago
  This is what cripples most indie hacking projects. The idea that if you build it well enough the customers will come to you. Right now, you need more selling than ever to get found and heard. Put this in perspective, even if you went down the low-touch, organic selling route of content marketing and you were building a MarTech product. You would as of my last check be competing against 2000+ MarTech SaaS all effectively blogging to the marketing department, every week. You then could switch to advertising but again, there's probably 200+ platforms already in your product area. Slow growth is the best growth, technical debt is minimized and you can call the customer directly to learn from them what they like and dislike. Which is still considered selling and unless you 'ship' you get no feedback. I feel like people are too focused on the 'meaning' of words when really, it's sink or swim when most products launch.
- valand 6y ago
  I don't feel the same way. I feel that "ship" feels like a larger scaled "deliver", while "sell" feels more focused on the transaction rather than the product. The evocation of image of frantic developers churning away might be coming from your previous experience working at or reading about that shipping culture. Unfortunately, I am exposed to that chaotic shipping culture too. I feel this disastrous shipping stories is everywhere, enhanced by the nature of software development that gets more social each day. At the end, it is the bad practices that leads to bad shipments that we must resolve. I'm comfortable to keep the original meaning and feel of the word "ship" to separate the bad practices from it and acknowledge them as problems -- the first step of a problem resolution.
hazz99 6y ago
Semi-related. Whenever I'm building something, I get really strong tunnel vision. Part of what makes me a good engineer – submerging myself extremely deep and specific context, "the zone" – seems to work against me becoming a good product person. There's always product stuff I seem to forget, or don't pay attention to, or I end up focusing on the wrong things. After "shipping", however, the tunnel vision goes away. I can view my work with a level of clarity. Some features I built might be valuable, and some won't. By splitting my work into build/evaluate phases, rather than continual building, I've become much better at focusing on the impact of what I'm building, and not the engineering in-and-of-itself. I have a terrible habit of spending too much time building, and not enough time thinking/marketing/etc. This is how I try to manage that.
- atoav 6y ago
  As someone who studied and worked at art school let me assure you, that this is quite normal. Some people just are better at changing their doing-hat to the editing- or evaluating-hat in a rapid fashion than others. Being (and staying) conscious about this is already 80% of the solution. However the real reality check is always when you have a room full of people look at ghe thing you made. If it helps, try to make rituals around the reflection part. Be it something simple as putting your hands into your pockets, making a cup of tea or showing it to a friend. Everything that gets you away, everything that makes you explain it to aomeone else etc. will help.
  - danybittel 6y ago
    For me, it really helps writing the documentation. I usually come back and change a feature while writing. I dislike explaining things to people, so I change it as much as possible so it becomes as easy and quick to explain. I call it DDD. Documentation Driven Development.
    - marcosdumay 6y ago
      When possible, I practice full DocDD (DDD is taken). I write a short documentation before the code, write the code, change the documentation to reflect the code, and then change the code to improve the documentation.
puchatek 6y ago
> Bill was wearing the same presenter shirt we all had to wear. Can somebody explain?
- erwincoumans 6y ago
  all presenters had to wear
- leg100 6y ago
  I'm pretty sure he didn't mean everyone had to share the same red shirt, passing it on between presentations. I for one would not have liked to wear it after Ballmer.
- fergie 6y ago
  This is something that MS makes you do when presenting at conferences (it a uniform rather than the same actual article of clothing of course)
  - teh_klev 6y ago
    Scott Guthrie's red polo short always made me chuckle, he wore it without fail on stage. And then at one conference the whole audience turned up in the same red polo.
ciconia 6y ago
> The biggest lesson a new team can have about shipping is that once you ship, it gets easier to do it as a team the next time. This is so true, and not only in software development. When you embark on a project that has to deliver a concrete result, the first time is hard, the second time is already much easier.
29athrowaway 6y ago
Shipping something does not mean you finished something. And not finishing something means you do not necessarily understand what you shipped.
johtela 6y ago
Being old enough to have used both Microsoft and Borland development tools back in the 90s, I think Borland was clearly ahead of the game in Windows development. GUI development with MFC was clunky and tedious. Tools generated ton of boilerplate code that you had to understand and maintain. Borland on the other hand offered much more developer friendly experience, especially when Delphi 1.0 came out on 1995. That was hands down the best development tool for Win16. They maintained the edge in Win32 development as well with Delphi 2.0. So, seeing all the dirty tactics MS employed to steer developers to using their tools just reminds me what an a-hole company they used to be.
- tecleandor 6y ago
  Oh! Delphi was way ahead, at least on the user experience, I remember VB6 not having 'undo' actions for form editing so if you sneezed and accidentally moved a bunch of elements in your form, well... And don't talk about VB redistributable, that weren't funny at all in the dial up era...
marshmallow_12 6y ago
reminds me of a joke; Renes Descartes walks into a bar. bartender asks him "a pint, Sir?" Descartes answers "i think no-" and promptly disappears.
ourmandave 6y ago
Negative, I am a minimum viable popsicle.
johnchristopher 6y ago
> Visual Basic pioneered the concept of making it easy to code GUI programs. The problem was that it was not viewed as a professional tool and was much more geared toward business app developers and not commercial C programmers IMO nothing came close to Visual Basic from that era. It really was a GUI builder IDE all in one. It would enforce a event based style of coding a decade before the coming of Flash. I still think HTML5 has not recaptured that (VB and Flash).
- PeterisP 6y ago
  IMHO Delphi was in some ways a better VB than VB itself.

301 points by jashkenas 6y ago

I am not a fan of the term "ship", similar to "sell". It's a horrible term. It evokes the image of a frantic imprudent developer churning away at ball of mud trying to meet their shipping metrics and feature bloat targets. Does anyone feel the same? If someone told me "I sold stuff, therefore I am", it just leaves a bad impression of them for me. Build stuff with care and craftsmanship. Strive for excellence, take pride in your work and deliver, not ship.

years3500 6y ago
You nitpick, therefore you are not cool.
- chuckSu 6y ago
  Comment of the week
thitcanh 6y ago
I am not a fan of the term “build”, similar to “deliver”. I’m more of a “manufacture” and “bring to life” kinda guy.
- machinelabo 6y ago
  I like those better. Craft is great as well.
  - quickthrower2 6y ago
    I like “unleash”
    - TeMPOraL 6y ago
      I prefer "expose", as in "expose to radiation" - it connotes long-term suffering of the users of my work.
      - quickthrower2 6y ago
        Or perhaps expose as in emperor has no clothes!
        TeMPOraL 6y ago
        My software does both!
keiferski 6y ago
Steve Jobs popularized the phrase “Real Artists Ship.” He was also famously obsessed with craftsmanship, especially of the parts that weren’t seen by users. https://thenextweb.com/apple/2011/10/24/steve-jobs-obsession-with-the-quality-of-the-things-unseen/ https://thenextweb.com/apple/2011/10/24/steve-jobs-obsession...
- ValentineC 6y ago
  It's so nice to see this article, and wonder what Apple was thinking when they were deciding what material to use for the insulation on their Lightning and (old) MagSafe cables. Original Apple cables seem to suffer from the insulation flaking over time — and Genius Bars all around the world (I've tried, many times) refuse to acknowledge that it's a manufacturing defect.
iagooar 6y ago
You can build something that is excellent, yet if you do not ship it, it will have no impact. Shipping to me is bringing a technical feature or increment to customers' hands. It is a product, yes. You sell it, true. There is nothing wrong with that if you are solving a problem or removing a pain.
steve_adams_86 6y ago
I’ve always thought the term and colloquial meaning in tech arose from the need to act on delivering, otherwise one could focus on craft almost perpetually.
SiVal 6y ago
No, I remember what it meant. Once you put a product on a ship and watch it sail away, you can no longer tinker with it. You might not feel finished, so it takes resolve. Finished or not, when it sails away, you're done. Back when software was treated as a physical packaged good, it had to physically leave your "factory" by a certain date to qualify as a sale during the quarter, allowing it to be claimed in a quarterly income filing, which would boost the stock price and, thereby, the compensation of execs and employees. So, the sales team would sometimes have to carry an armload of shrinkwrapped boxes out the back door into the parking lot to claim a sale for that quarter. It had legally "shipped". The programmers (former high school nerds) would be desperately hanging on to the code until the last possible minute--there was always more that ought to be done--while the sales team (former high school jocks) would be forcing the programmers to "hand over that disk, now, nerd!" No courage was required by the sales team to ship. Their job was just to book the sale. In the parking lot by midnight? Hello sales bonus. But real courage (or threat) was required by the programmers, who would be forced to let go of code that could not be fixed "thru the wire" in those days, knowing that they would be blamed for every flaw that they "shipped".
- deleted 6y ago
  [deleted]
- machinelabo 6y ago
  Oh I remember when video games used to be shipped in that they had to finish everything. No patches later. It’s going to get burned on the ROM and off it goes sailing to their customers. Now a days, shipping to me evokes “Fuck it, ship this shitty MVP to customers because ship ship ship” and then they wonder “Gee, why didn’t my app take off?”. I understand the need to ship, but I never see anyone daring to challenge the frantic broken shitty app philosophy and maybe wondering if they built them with care, maybe... just maybe customers with actually come? Has anyone tried to go against the grain since the SEGA days? It’s high risk. Thanks for a great perspective.
  - paulryanrogers 6y ago
    As a counterpoint, I've a janky product that I've soft launched. It's definitely a rough beta. But because of churn on the underlying platforms it'd be a constant, full time battle to polish out all bugs. Even then some quirks may never be fixed because web extensions aren't technically meant to allow interrupting all means of browser navigation. And for me it's all a (sometimes not so) fun little side project. If I had never launched at all then it's possible no one would ever get the benefit of my unique feature. There are similar competitors which I'd rather just buy and use, yet they don't have the one killer feature I wanted.
melomal 6y ago
This is what cripples most indie hacking projects. The idea that if you build it well enough the customers will come to you. Right now, you need more selling than ever to get found and heard. Put this in perspective, even if you went down the low-touch, organic selling route of content marketing and you were building a MarTech product. You would as of my last check be competing against 2000+ MarTech SaaS all effectively blogging to the marketing department, every week. You then could switch to advertising but again, there's probably 200+ platforms already in your product area. Slow growth is the best growth, technical debt is minimized and you can call the customer directly to learn from them what they like and dislike. Which is still considered selling and unless you 'ship' you get no feedback. I feel like people are too focused on the 'meaning' of words when really, it's sink or swim when most products launch.
valand 6y ago
I don't feel the same way. I feel that "ship" feels like a larger scaled "deliver", while "sell" feels more focused on the transaction rather than the product. The evocation of image of frantic developers churning away might be coming from your previous experience working at or reading about that shipping culture. Unfortunately, I am exposed to that chaotic shipping culture too. I feel this disastrous shipping stories is everywhere, enhanced by the nature of software development that gets more social each day. At the end, it is the bad practices that leads to bad shipments that we must resolve. I'm comfortable to keep the original meaning and feel of the word "ship" to separate the bad practices from it and acknowledge them as problems -- the first step of a problem resolution.

hazz99 6y ago

Semi-related. Whenever I'm building something, I get really strong tunnel vision. Part of what makes me a good engineer – submerging myself extremely deep and specific context, "the zone" – seems to work against me becoming a good product person. There's always product stuff I seem to forget, or don't pay attention to, or I end up focusing on the wrong things. After "shipping", however, the tunnel vision goes away. I can view my work with a level of clarity. Some features I built might be valuable, and some won't. By splitting my work into build/evaluate phases, rather than continual building, I've become much better at focusing on the impact of what I'm building, and not the engineering in-and-of-itself. I have a terrible habit of spending too much time building, and not enough time thinking/marketing/etc. This is how I try to manage that.

atoav 6y ago
As someone who studied and worked at art school let me assure you, that this is quite normal. Some people just are better at changing their doing-hat to the editing- or evaluating-hat in a rapid fashion than others. Being (and staying) conscious about this is already 80% of the solution. However the real reality check is always when you have a room full of people look at ghe thing you made. If it helps, try to make rituals around the reflection part. Be it something simple as putting your hands into your pockets, making a cup of tea or showing it to a friend. Everything that gets you away, everything that makes you explain it to aomeone else etc. will help.
- danybittel 6y ago
  For me, it really helps writing the documentation. I usually come back and change a feature while writing. I dislike explaining things to people, so I change it as much as possible so it becomes as easy and quick to explain. I call it DDD. Documentation Driven Development.
  - marcosdumay 6y ago
    When possible, I practice full DocDD (DDD is taken). I write a short documentation before the code, write the code, change the documentation to reflect the code, and then change the code to improve the documentation.

puchatek 6y ago

> Bill was wearing the same presenter shirt we all had to wear. Can somebody explain?

erwincoumans 6y ago
all presenters had to wear
leg100 6y ago
I'm pretty sure he didn't mean everyone had to share the same red shirt, passing it on between presentations. I for one would not have liked to wear it after Ballmer.
fergie 6y ago
This is something that MS makes you do when presenting at conferences (it a uniform rather than the same actual article of clothing of course)
- teh_klev 6y ago
  Scott Guthrie's red polo short always made me chuckle, he wore it without fail on stage. And then at one conference the whole audience turned up in the same red polo.

ciconia 6y ago

> The biggest lesson a new team can have about shipping is that once you ship, it gets easier to do it as a team the next time. This is so true, and not only in software development. When you embark on a project that has to deliver a concrete result, the first time is hard, the second time is already much easier.

29athrowaway 6y ago

Shipping something does not mean you finished something. And not finishing something means you do not necessarily understand what you shipped.

johtela 6y ago

Being old enough to have used both Microsoft and Borland development tools back in the 90s, I think Borland was clearly ahead of the game in Windows development. GUI development with MFC was clunky and tedious. Tools generated ton of boilerplate code that you had to understand and maintain. Borland on the other hand offered much more developer friendly experience, especially when Delphi 1.0 came out on 1995. That was hands down the best development tool for Win16. They maintained the edge in Win32 development as well with Delphi 2.0. So, seeing all the dirty tactics MS employed to steer developers to using their tools just reminds me what an a-hole company they used to be.

tecleandor 6y ago
Oh! Delphi was way ahead, at least on the user experience, I remember VB6 not having 'undo' actions for form editing so if you sneezed and accidentally moved a bunch of elements in your form, well... And don't talk about VB redistributable, that weren't funny at all in the dial up era...

marshmallow_12 6y ago

reminds me of a joke; Renes Descartes walks into a bar. bartender asks him "a pint, Sir?" Descartes answers "i think no-" and promptly disappears.

ourmandave 6y ago

Negative, I am a minimum viable popsicle.

johnchristopher 6y ago

> Visual Basic pioneered the concept of making it easy to code GUI programs. The problem was that it was not viewed as a professional tool and was much more geared toward business app developers and not commercial C programmers IMO nothing came close to Visual Basic from that era. It really was a GUI builder IDE all in one. It would enforce a event based style of coding a decade before the coming of Flash. I still think HTML5 has not recaptured that (VB and Flash).

PeterisP 6y ago
IMHO Delphi was in some ways a better VB than VB itself.