[HN Gopher] I Shipped, Therefore I Am
___________________________________________________________________
I Shipped, Therefore I Am
Author : jashkenas
Score : 277 points
Date : 2021-03-12 03:59 UTC (19 hours ago)
(HTM) web link (hardcoresoftware.learningbyshipping.com)
(TXT) w3m dump (hardcoresoftware.learningbyshipping.com)
| puchatek wrote:
| > Bill was wearing the same presenter shirt we all had to wear.
|
| Can somebody explain?
| fergie wrote:
| 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 wrote:
| 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.
| erwincoumans wrote:
| all presenters had to wear
| leg100 wrote:
| 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.
| hazz99 wrote:
| 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.
| TheColorYellow wrote:
| > 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.
|
| I feel a lot of this from the other side of the table. Part of
| what works against me in engineering is my lack of fluency in
| focusing deeply on very insulated challenges for a long enough
| period of time. I've always said this works against me but
| makes me great at the product side of the house because I can
| leverage my natural inclinations better.
| rpastuszak wrote:
| I've been struggling with something similar, although I think
| that in my case it's tunnel vision and the impostor syndrome.
|
| I often get completely lost in the minute details, and find it
| really, I mean, really hard to move on to more important things
| in the bigger picture.
|
| Then, just getting stuff out and sharing it with people becomes
| a chore as soon as I'm done with the more difficult parts of
| work.
|
| Things I've tried:
|
| - follow TDD and XP, Design Thinking/HCD (iterative
| methodologies that allow you to slice problems differently,
| split them into smaller chunks)
|
| - Build smaller products/tools (most of my apps are really,
| really tiny, an old example: http://facade.photo)
|
| - Build a tool to separate writing from editing
| (https://sonnet.io/posts/ulysses/)-I've been using it every day
| for the past 1.5y
|
| - Force taking regular breaks, even if I'm focused, to regain
| context (pomodoro)
|
| - therapy (I got to the point where building a calculator in JS
| took me a week, which made me realise that maybe there are some
| deeper problems at play here)
|
| I was at the point where I would run courses on having this
| high-level perspective: XP, pairing, workshops on Human Centred
| Design, and ironically, I find all of that paralysing in my
| solo work. So, I guess the last point from the list (therapy,
| taking time off) seems to be the most helpful one. I still find
| all of that extremely frustrating, almost destructive.
|
| Side note: either Clean Coder or Pragmatic Programmer
| criticises being "in the zone"/the state of flow precisely for
| the reason you've mentioned. I recommend reading both, although
| I think the approach to the craft they describe is to put it
| mildly, draconian.
| hinkley wrote:
| One of the characteristics of Flow State is
|
| > A loss of reflective self-consciousness
|
| Developers who spend all their time in flow state are not
| thinking about other people. Worse still, in many cases their
| emotional attachment to the code they wrote in Flow can be very
| high, leading to defensiveness and rationalization.
|
| Really any time you write a module _someone_ will take issue
| with how you did it, so it can be a little difficult to discern
| if "you do it too". If you can make most of your decisions
| outside of Flow, this seems to go a bit better in this respect.
|
| If you get stuck, leave your desk, snap out of it. _Think._
| Which is another way of saying that if you're going to rely on
| Flow then you'd better figure out how to drop in and out of it
| more or less at will.
| chrisweekly wrote:
| Yeah; related tangents: I think it was Dr Ben Hardy whose
| advice resonated best with me: "Always make decisions in your
| peak energy state". It means I'm sometimes overly ambitious
| or set the bar too high, but overall it serves me well.
|
| Also, acknowledging and leveraging different modes of
| thinking: "open" or expansive, broad, associative, free-form
| on one hand vs "closed" or focused, directed, narrow, deep on
| the other. We tend to associate flowstate with the latter,
| but some of the most profound and impactful work I've ever
| produced has stemmed directly from the former.
|
| So many thoughts here; this topic fascinates me.
| klingon78 wrote:
| When and how do you transition from thinking/marketing/etc. to
| building?
|
| And how do you handle situations where:
|
| (1) you know you must ship, but it's not good enough?
|
| (2) you know you must think/market/etc., but you're building?
| mmcdermott wrote:
| A lot of it comes down to being intentional. You can only fit
| so many features (functional and non-functional) into any
| given time window. So you are either selecting the features
| and allowing the time window to expand to accommodate it or
| removing features to hit the window. There can be some
| negotiation for sure, but those are your levers.
|
| I think staring this fundamental truth in the face goes a
| long way. Very few projects can allow the development window
| to expand indefinitely. A startup needs customers and
| feedback, even if only for another funding round. An
| established company generally has deadlines driven directly
| or indirectly by customers. Both can slip a little, but not
| indefinitely. Not all features are strictly necessary. So you
| optimize for time and importance.
|
| The hardest thing to get over is that you will never think
| it's good enough because it could always be better. But
| existence is a feature. The ultimate feature. So you'll have
| to ship an imperfect product and iterate. Experience usually
| gives better hand-holds on shipping something.
|
| I also tend to find that half-features please no one. You're
| better off either finishing something or cutting it.
| hazz99 wrote:
| I'm the most dysfunctional wannabe founder ever, so I am 100%
| not qualified to answer this :)
|
| With that said, I think product/solution ambiguity is rooted
| in confusion about the problem being solved. It comes from
| starting with an idea, and not a painful problem that people
| already experience. Alternatively, from a problem that
| exists, but is incredibly ill-defined.
|
| It would be disingenuous for me to comment further, because
| I'm still learning! My view is it's easy to create a
| solution, but really hard to find & well-define a really
| painful problem.
| klingon78 wrote:
| My biggest problem is thinking instead of building.
|
| I've had and still have some great ideas, and that's all
| they amounted to thus far.
|
| When I've started to build, I get stuck spending a lot of
| time to produce very little, because I try to implement a
| novel way to do something simple that no one would want
| while deploying it easily and handling requests quickly.
|
| My greatest dream is that I write something eventually that
| actually works and that people would want to use.
|
| My greatest fear is that either that no one would use it,
| because I don't need it or understand the need for it, or
| that it would work, not scale, and I'd have leveraged
| everything and let everyone and myself down.
|
| Also, execution bores me. It's more fun ideating, thinking
| and analyzing, but I'd like to be responsible for creating
| things that are interesting and solve problems or make life
| better.
|
| I'm unsure where the risk-averse creative fits into a
| startup CEO role.
| throwaway98797 wrote:
| Your fear assures your fate.
|
| Accept that is the case and let yourself code anyways.
| Then you may end up being surprised by what you can
| accomplish.
| Cthulhu_ wrote:
| I feel that. Writing code and zooming in on individual tasks is
| much more my jam than zooming out and seeing the whole picture.
|
| At my current job I kinda have to do all of them, I'm the solo
| developer on the UI of our application (my colleagues work on
| the C runtime, the UI generates configuration for it and shows
| diagnostics and statistics data). What this project really
| needs though is more people working on it, and the way things
| stand I'd be in the lead there, so I have to take a step back
| from the nitty-gritty.
| atoav wrote:
| 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 wrote:
| 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 wrote:
| 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.
| OJFord wrote:
| You may realise this, but DDD usually refers to 'Domain
| Driven Development'.
| hazz99 wrote:
| > Some people just are better at changing their doing-hat to
| the editing- or evaluating-hat in a rapid fashion than others
|
| I only recently realised that, for me, "dev mode" and
| "product mode" are entirely distinct. I'd been trying to mush
| them together in a haphazard way, with haphazard results.
|
| In my opinion, this is a really important insight. It's
| analogous to the De Bono thinking hats, divergent/convergent
| thinking, etc - distinct phases of cognition that can't
| happen simultaneously.
|
| > If it helps, try to make rituals around the reflection
| part.
|
| Great idea! Is this something you learned in art school?
|
| In my experience, every art student seems to incredible at
| "shipping". I've always been jealous. Way better than most CS
| or business grads. I guess it's a core part of the degree?
| agustif wrote:
| There's the famous study about 2 groups of pottery class,
| one group was asked to make one perfect vase, the other to
| make as many vases as possible...
|
| Guess which one ended up with just not more vases but much
| better quality ones...
|
| Focused/directed practice makes perfect, each iteration
| your brain is strengthening the pathways associated to that
| activity, making it easier for you to add more
| nuance/attention to detail at each iteration...
|
| One can always keep practising without focusing in
| improving, which isn't as useful...
| polytely wrote:
| Strong agree, for me the idea of showing something to a
| colleague immediately makes me able to view it from a
| different lens. Regular design critiques are really valuable,
| even if the person you are showing it too isn't an expert,
| because it gets you into a different mode of thinking, you
| can't do mental shortcuts when you are actually explaining
| things so it forces you to be concrete.
| mattbuilds wrote:
| They idea of turning it into a ritual is awesome. I'm
| definitely going to try that because it's something I've
| struggled with in the past. I find building things into
| habits is the only way to maintain them in the long term.
| hallqv wrote:
| Elon said it well in an interview regarding Starship
| development, "most common problem in engineering is optimizing
| something that shouldn't have been built in the first place",
| https://www.youtube.com/watch?v=cIQ36Kt7UVg
|
| Broaden your view. You are not put on earth to write great
| code, but to solve real world problems. Software development is
| a means to an end, not the end itself.
| afarrell wrote:
| Sometimes though, the engineering exists to create art.
| Because we are all human and we all in our own way yearn to
| answer the question "What is beauty?"
|
| Including the folks at Valve.
| valand wrote:
| Well, Elon and SpaceX has the luxury of having a total
| control of the product's technical requirement.
|
| Most probably this is because Elon, being the CEO, has enough
| technical prowess to oversee both the real-world requirement
| and technical aspect of the product. This allows the company
| to streamline the practical/from-real-world requirement and
| the technical specification, therefore eliminating "things
| that shouldn't have been built in the first place".
|
| This is luxurious because other tech company either does not
| have and/or does not realize it must procure.
|
| One of my personal daydream is to be in a period where this
| streamlined real-world requirement and technical
| specification is common, not a luxury.
| hallqv wrote:
| Excuses. What organization your work for is a choice you've
| made. You need to make sure you work for a well functioning
| one, few things are more important. If you can't get hired
| by one, start one yourself.
| valand wrote:
| Not excuses. I'm pointing out that to achieve the
| streamlined real-world-tech-spec, you need that kind of
| person.
|
| My wish is not only for my organization but for
| everybody. The world might be a better place if things
| are cheaper to maintain.
| hallqv wrote:
| You don't need to be Elon Musk to think hard about if you
| are optimizing for solving real world problems or
| something else. It's a habit of mind and the courage to
| change your circustances if you find yourself in a
| situation where it's not possible do things the right way
| (e.g. in a dysfunctional organization).
| tome wrote:
| Relevant similar quotations:
| https://quoteinvestigator.com/2017/02/09/efficient/
| teekert wrote:
| This level of knowing oneself is gold. The older you get, the
| better you get at managing your self and your (sub-optimal,
| emotional, human) tendencies.
|
| When you are young you may think that you can just adapt to
| anything (I did). But you often can't. You will be lazy,
| procrastinate, feel like you deserved a relaxing day, get
| cranky for (un)known reasons, etc. You will have emotions, and
| they are not rudimentary things you can ignore because the
| annoy you from time to time. They are you and they need to be
| listened to and understood.
|
| This is what experience is to me: Getting to know yourself and
| riding your own waves of enthusiasm and productivity and
| knowing when to stop and reflect or seek help or when to accept
| your shortcomings and move on without shedding tears. To know
| when you are fooling yourself and know that you will get
| disappointed in yourself and will develop negative emotions and
| learn how to avoid that by being more realistic about your
| abilities (and time management skills).
|
| More an more I accept deep down that I won't be the next
| president or the next Steve Jobs even though my parents told
| you I could do anything I set my mind to! And I know that that
| is ok.
| agustif wrote:
| Great insights.
|
| > parents told you I could do anything I set my mind to! And
| I know that that is ok.
|
| Well that truism only misses nuance, it's really true you
| can/could/will do anything you want, If you do believe in
| free will after all.
|
| I would just add the stoicism on internal/external locus of
| control.
|
| IMHO the part parents mostly miss, is you cannot control how
| others, as in other humans, society, et all, will react to
| you/your actions/your creations, or if you will even be
| noticed or not before you're out of the game...
|
| Just look at all the bullshit some scientists, artists,
| businessmen, etc or anyone trying to challenge the status
| quo, had to go through just for the mere fact that their
| ideas didn't match those of their time...
| Toine wrote:
| That was satisfying to read. I think many devs have the same
| issue and are not nearly as impact-driven as they should be.
| Let's start another cult : Impact Driven Development
| hyperpallium2 wrote:
| Engineering and marketing have contradictory value-systems, so
| it's easier to have them in separate people.
|
| I wonder if separate rooms, with distinct smells, and wearing
| different hats would ease the transition.
| hyperpallium2 wrote:
| I'll elaborate: engineering's value-system is about intrinsic
| value; marketing's value-system is about extrinsic value.
|
| Engineering is about the thing itself; marketing is about the
| market. Engineers want the thing itself to be good, by
| various metrics; marketing is motivated by market needs/wants
| and competition/alternatives.
|
| For example, coherence and high performance are properties of
| a product, that an engineer might value. But for the market,
| a shopping list of properties at good-enough performance, may
| be what's needed.
|
| OP's "tunnel vision", undistracted by the market, is how the
| best engineering is done. But of course, maybe nobody wants
| or needs this - that's the role of marketing.
|
| Typically, engineering is market-led, with the marketing
| deciding what is to be built and engineering building it. But
| because engineers can create things that the market didn't
| imagine was feasible, it is sometimes engineering-led.
|
| Henry Ford apparently said the market would have wanted
| "faster horses".
|
| Startups ideally exist at this intersection, where engineeing
| creates things that never were, and marketing creates needs
| that never existed.
|
| Note startups are often co-founded by a duo of
| engineering/marketing - because these inconsistent value-
| systems are easier to have in separate people.
| afarrell wrote:
| Engineering at its worst and marketing at its worst have
| contradictory value systems.
|
| At their best though, they are as harmonious as art and
| mathematics.
|
| https://www.youtube.com/watch?v=-vZ_E1OO_PY
| throwaway98797 wrote:
| Depends on your lens.
|
| Both solve problems.
| nojvek wrote:
| Yeah the plan -> build -> evaluate cycle is a healthy way to
| ship. I do that too. Monday are my plan days with lots of
| alignment meetings.
|
| Friday's are my evaluate days with tons of both customer and
| internal calls to get feedback.
|
| Tue-wed are my build days. I try to not to have any meetings
| after lunch. That is my in-the-zone time.
| chrisweekly wrote:
| I'm on the other end of that curve; I tend towards thinking and
| mentally mapping / exploring permutations and implications at
| the expense of build/ship/iterate. I've learned to adopt a bias
| to action when called for, but it's a conscious effort. IMHO
| teams with a range of cognitive styles are the most effective.
| mejutoco wrote:
| I have realized something similar recently.
|
| When building a website I would use bootstrap or similar to
| design the website as I implemented it.
|
| Recently I have been designing the website in figma some days,
| and implementing said design other days, and my productivity
| had skyrocketed.
|
| For me, it simulates a boss giving me requirements. I can focus
| on the task at hand without context switching all the time (or
| that is my rationalisation)
|
| Edit: typos
| hazz99 wrote:
| Yes! I discovered the same thing, but with Sketch. I think
| it's because you can explore the problem space, and converge
| on solution, much faster when you don't have to bother with
| code.
|
| Going further down that line of thought, pen and paper
| _really_ works. You don 't have to bother with colours, fonts
| and rounded edges.
|
| A fun exercise I do, when solving a creative problem, is
| this:
|
| 1. Divide a sheet of paper into 8 squares
|
| 2. Set a timer for 40 to 60 seconds
|
| 3. For each square, start the timer, and attempt to draw a
| different solution in each box
|
| This forces you to stop worrying about the individual ideas,
| and focus on generating lots of them. It also gets you past
| the "immediate solution" thoughts you have, and into more
| interesting ones.
|
| At the end, you can collate the ideas, and pick the best
| parts from each one.
| snarfy wrote:
| Reading these comments has me asking "Does nobody use
| whiteboards anymore? Do they just start coding?"
| TeMPOraL wrote:
| That's a great trick, I'm going to steal it! I tend to
| naturally go somewhat depth-first instead of breadth-first,
| and the quality of my idea generation often depends on how
| much working memory I have, and how big is the canvas on
| which I put my notes (I really like my infinite virtual
| whiteboard on my sidearm computer).
|
| The split also applies to developing code. I've learned to
| switch quickly between two modes: I either focus on typing
| code, or on architecture/design decisions. When I coding is
| getting hard - I feel lost, unsure about what to write - I
| switch to design mode. When I feel I have something
| conceptually sound and my brain doesn't want to generate
| more ideas, I switch back to coding. This can happen
| multiple times per day. The point is to be always working
| in the mode that's easier to make progress in at a given
| moment.
|
| It's probably an obvious technique to many, but I've worked
| with people who struggled with making these switches - they
| tried to power through coding even though it turned
| spaghetti, or considered "design phase" to be something Big
| to be done seldomly and up front. But it's wrong. The mode
| switch isn't a big deal - preserving the context in your
| head is. I solve that by writing down any outstanding
| thoughts before mode-switching. Often as a string of //TODO
| //FIXME //NOTE in code.
| chrisweekly wrote:
| > "(I really like my infinite virtual whiteboard on my
| sidearm computer"
|
| what software do you use for your infinite virtual
| whiteboard?
|
| EDIT: whoops, just saw my Q was redundant; thanks for
| responding to the other comment
| TeMPOraL wrote:
| https://concepts.app/en/
| PebblesRox wrote:
| I keep a running project journal in a google doc with to-
| dos and just stream-of-consious thought about the problem
| at hand. If I have an idea for something that's not a
| current priority, I put it in under an out-of-scope
| header. I can come back and collect it later when I'm in
| a big picture planning phase and it lets me stop carrying
| the mental weight of "I want it to be perfect" that leads
| to paralysis because I can't implement everything all at
| once. Writing down my thinking helps recover from
| interruptions, which are frequent with kids underfoot.
| rasen58 wrote:
| What is a sidearm computer? How do you manage your
| infinite canvas?
| TeMPOraL wrote:
| It's how I call the computer I use in situations when I
| can't use my primary computer. E.g. on the bus, in the
| bed, while going for a trip. My primary computer is a
| powerful desktop machine, and I pick the supporting
| computer to be light and mobile, but preferably powerful
| enough to handle sophisticated tasks on its own.
|
| (This is through analogy to a soldier, who carries a
| primary weapon - perhaps one that's heavy and unwieldy,
| like an anti-materiel sniper rifle, or one that they
| can't move by themselves, like in artillery teams - but
| is also issued with a pistol as sidearm. While having
| limited range and lethal power, a sidearm can also be
| grabbed, aimed and discharged quickly, and can be carried
| and used in situations where the primary weapon cannot.)
|
| My current sidearm is a Dell 5290 2-in-1, with a stylus.
| Basically a cheaper version of Microsoft Surface. I use a
| vector drawing app called Concepts[0], which offers an
| infinite canvas, and is streamlined for use on tablets
| with pens. This is as close to a good whiteboard
| experience as you can get on a computer - you draw as if
| on paper, and then freely pan/rotate/zoom the canvas (or
| your drawings).
|
| I don't really manage my canvas, I just keep the app
| open, make drawings and notes and diagrams, and
| occasionally sort them into "galleries" when the main
| screen gets too crowded.
|
| --
|
| [0] - https://concepts.app/en/, has versions for Windows
| UWP, Android and iOS.
| codethief wrote:
| I've used that method, too, with great success! Are you
| familiar with design sprints[0]? I think I learned it from
| there. FWIW, design sprints are a really good method to
| find a solution to a given issue in a decent amount time[1]
| (not too slowly but not too fast, either, as to not
| overlook alternative, superior solutions).
|
| [0]: https://designsprint.org/
|
| [1]: Those 4 days they mention on the website can often be
| reduced to a day or two once you've already done the sprint
| in the same problem area a few times (and provided you're
| tackling a small enough and specific enough issue with your
| sprint).
| johtela wrote:
| 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 wrote:
| 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...
| 29athrowaway wrote:
| Shipping something does not mean you finished something.
|
| And not finishing something means you do not necessarily
| understand what you shipped.
| marshmallow_12 wrote:
| 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 wrote:
| Negative, I am a minimum viable popsicle.
| machinelabo wrote:
| 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.
| iagooar wrote:
| 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 wrote:
| 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.
| valand wrote:
| 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.
| SiVal wrote:
| 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".
| fritzo wrote:
| Exactly. I see a beaming and anxious engineer standing at the
| railing of a wharf, watching a cargo ship slowly and
| unstoppably glide away to a distant port. As the engineer's
| scarf flutters in the wind she looks down at her trembling
| hands, hands detached from their creation, hands with energy
| and nothing to do, hands that slowly acknowledge the building
| phase is over. Now it's time to evaluate.
| [deleted]
| machinelabo wrote:
| 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 wrote:
| 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.
| blacktriangle wrote:
| If you change the metaphor a bit "ship" sounds good. Except
| instead of putting the product on the ship, the product is
| the ship, and once you've shipped out you now have to
| maintain that ship with no land in sight, supplies running
| low, and the crew grumbling mutiny.
| years3500 wrote:
| You nitpick, therefore you are not cool.
| chuckSu wrote:
| Comment of the week
| melomal wrote:
| 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.
| thitcanh wrote:
| 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 wrote:
| I like those better. Craft is great as well.
| quickthrower2 wrote:
| I like "unleash"
| TeMPOraL wrote:
| I prefer "expose", as in "expose to radiation" - it
| connotes long-term suffering of the users of my work.
| quickthrower2 wrote:
| Or perhaps expose as in emperor has no clothes!
| keiferski wrote:
| 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...
| ciconia wrote:
| > 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.
___________________________________________________________________
(page generated 2021-03-12 23:02 UTC)