[HN Gopher] Working quickly is more important than it seems (2015)
___________________________________________________________________
Working quickly is more important than it seems (2015)
Author : cal85
Score : 253 points
Date : 2023-06-13 16:08 UTC (6 hours ago)
(HTM) web link (jsomers.net)
(TXT) w3m dump (jsomers.net)
| karaterobot wrote:
| This is kind of conflates the idea of a person doing a job
| quickly, and the idea of tools having low latency/quick response,
| which confuses the issue if what you care about is working
| quickly -- the bottleneck for work is usually the speed of our
| thinking, or the limits of our motivation to work. But, it's
| usually not the speed of our tooling. You wouldn't become a
| better programmer with a faster computer, and usually not a more
| effective one either. I'll ignore the second definition.
|
| In my opinion, you want to spend about as much time as ever, but
| spend more of your time working on something that is close to a
| solution. So, you want to work on the first draft as quickly as
| possible, so you can either refine it, or toss it out and do
| another iteration. The advantage is overall quality and
| confidence in your solution.
|
| For reasons mentioned in the article, I do not prefer to be
| thought of as working quickly and well, since that often means
| someone sees your first draft and says "great, looks like you're
| done, now let me give you something else to work on". Better to
| have a reputation for taking about as long as most people, but
| producing better results.
| epolanski wrote:
| > You wouldn't become a better programmer with a faster
| computer, and usually not a more effective one either.
|
| Disagree, any time I have to wait for tools is a tragedy.
|
| I've definitely became much more productive at each computer
| upgrade.
| gen_greyface wrote:
| related: Some reasons to work on productivity and velocity
|
| https://news.ycombinator.com/item?id=28882043
| Slower-McSlower wrote:
| [flagged]
| ChildOfChaos wrote:
| I'm very slow at doing things, because I consider things too
| much, I very much believe this is the main skill I need to work
| on, because the quicker you do something, the quicker it goes
| wrong, so you can course correct.
|
| The book Creativity INC by Ed Catmul talks about this and they
| actually studied it at Pixar and they discovered the teams that
| moved faster were the best, the teams that considered everything
| for much longer, were wrong just as much as the teams that moved
| quickly, the only difference is because the other team moved
| quickly they could course correct sooner and also they were less
| tied into there original idea, so happy to drop it and go the
| other direction, were as the team that was slower and more
| considered took longer to drop the non-working idea, as they dug
| deeper and tried to make it work, since they were more invested
| in it.
| hot_gril wrote:
| When I got my first big corp job at a FAANG company, in the first
| week a senior dev gave me the worst work advice I've ever
| received: "Always write code as if you expect it to be around for
| at least 10 years."
|
| I think that's how that dept was doing things, and it was
| paralyzing. This was business logic that needed flexibility, not
| something like an OS kernel. Not only did new features not get
| shipped, but the pedantic approach actually caused tech debt
| because better solutions were seen as too hard. Code really _did_
| sit around for 10 years, and not because it was good code (it
| wasn 't).
| allenu wrote:
| Speed is underrated. I've worked on a lot of side projects and
| for a long time I couldn't get them done. I spent too long
| "perfecting" baseline things like folder structure (really) and
| overall system design. This made things slow-going and I tended
| to abandon them.
|
| Over time, I started just hacking things together and shipping
| them, worrying less about perfecting those initial things. (I
| used YAGNI a lot in my decision-making.) What I learned is that
| there were so many more things I had to do and had to learn to do
| to ship. I could only get to those tasks and learn those skills
| by "skipping" through the earlier tasks. Working quickly helped.
|
| I started thinking of projects as this vertical stack of work
| that you move up from bottom to top. If you could look
| holistically at absolutely everything you needed to do to ship a
| project, you could mark some as having a larger impact on the
| success of the project than others. Those are things that require
| more time and energy.
|
| When you move slowly, you have a very small scope of the overall
| project, just stuff at the bottom, and predictions about the
| future. You may not really know what's ahead. If you go slowly
| and try to do everything perfectly down there, you spend a lot of
| energy on a small subset of tasks which may actually have smaller
| impact than something in the middle or towards the end.
|
| Speed allows you to move through those early tasks move towards a
| more holistic view of the entire system so that you can determine
| which are high impact and which are not. You might need to
| double-back on an earlier task if you misjudged something as low-
| impact and ended up spending less time than you should on it, but
| at least you're not pouring energy into low-impact tasks on
| average.
|
| It's not quite the same thing, but building a prototype is a good
| example of learning the end to end of a system without worrying
| too much about quality. It gives you an initial idea of what's
| possible and you use that to get a better picture of what's high
| and low impact in a project.
| hot_gril wrote:
| This is all true. The SWEs I work with in a corporate
| environment don't get it, but the managers do.
| deely3 wrote:
| Am I right that you are talking only about quick creation of
| something new and not about long term support of created
| system?
| hot_gril wrote:
| It's both. The long-term improvements have to be done in
| small increments too.
| Sharlin wrote:
| > I've noticed that if I respond to people's emails quickly, they
| send me more emails.
|
| > It is a truism, too, in workplaces, that faster employees get
| assigned more work.
|
| Maybe there's irony I'm failing to perceive, but how exactly are
| these supposed to be _good_ things from the fast worker 's
| viewpoint? The truism is that working quickly is only rewarded by
| being assigned more work that's expected to be done even faster,
| which is a vicious circle if ever there was one!
| [deleted]
| perlgeek wrote:
| > I've noticed that if I respond to people's emails quickly, they
| send me more emails.
|
| This is why I intentionally wait before answering emails that
| aren't related to my core responsibilities. I want fewer of
| these, so I best not establish a reputation as somebody who
| quickly provides an answer to everything. Got other things to do
| :-)
| rglover wrote:
| The best solution I found to this logjam was this quote:
|
| > "Make haste slowly." - Baltasar Gracian
| littlekey wrote:
| We can go older: "festina lente" in Latin.
| (https://en.wikipedia.org/wiki/Festina_lente)
| 0x6461188A wrote:
| I agree with his points. The question is: what are some ways of
| working fast without being sloppy? Would be interested in how
| people here do it.
| hgsgm wrote:
| 1. Slow is smooth and smooth is fast. Don't rush and crush.
|
| 2. Practicing to get faster at the nitty gritty boring details,
| relying less on your reference materials, is as important as
| the big ideas.
| heisenbit wrote:
| > Whereas the fast teammate--well, their time feels cheap, in the
| sense that you can give them something and know they'll be
| available again soon. You aren't "using them up" by giving them
| work.
|
| Well that is not always true. Producing results is one thing,
| making sure you learn enough in that process is another. Managers
| eager to cram down one micro manage task after another will use
| up a persons knowledge without restocking it. Yes faster can be
| better as lot's of people agree here with but there are limits.
| tempestn wrote:
| > Now, as a disclaimer, I should remind you of the rule that
| anyone writing a blog post advising against X is himself the
| worst Xer there is. At work, I have a history of painful
| languished projects, and I usually have the most overdue
| assignments of anyone on the team. As for writing, well, I have
| been working on this little blog post, on and off, no joke, for
| six years.
|
| And, amusingly, it currently loads really slowly too.
| tasuki wrote:
| A good post overall, but the final paragraph is particularly
| great:
|
| > Now, as a disclaimer, I should remind you of the rule that
| anyone writing a blog post advising against X is himself the
| worst Xer there is. At work, I have a history of painful
| languished projects, and I usually have the most overdue
| assignments of anyone on the team. As for writing, well, I have
| been working on this little blog post, on and off, no joke, for
| six years.
| npilk wrote:
| In addition to the many great points made in the article, I would
| add that speed does a couple of other things for you:
|
| - The faster you finish work, the more time you have to make your
| work better
|
| - The faster you are even at things like browsing HN or Reddit,
| the more value you get per hour (e.g. seeing more new ideas,
| reading more blog posts, etc)
| lancebeet wrote:
| This reminds me of Steve Yegge's classic blog post "Programming's
| dirtiest little secret"[0]. Yegge's post is of course about
| touch-typing, but it essentially makes the same argument. Doing
| things slowly is a liability, not primarily because it consumes
| more time, but because it makes you opt out of doing certain
| things because of their perceived cost.
|
| [0] http://steve-yegge.blogspot.com/2008/09/programmings-
| dirties...
| neom wrote:
| "You'd be absolutely astonishedly flabbergasted at how many
| programmers don't know how to READ. I'm dead serious. You can
| learn to speed read even faster than you can learn to type, and
| yet there are tons of programmers out there who are unable to
| even skim this blog. They try, but unlike speed readers, these
| folks don't actually pick up the content."
|
| Heh!
| cosmiccatnap wrote:
| I always see arguments for working faster. Never arguments for
| taking your time to get solutions correct even if it doesn't
| produce something immediately visible.
|
| ...I'm sure there is no economic correlation
| hgsgm wrote:
| Being more productive is more valuable and profitable.
|
| "Correct" doesn't sprout fully grown from your head like Athena
| from Zeus
| divbzero wrote:
| Related:
|
| _Speed matters: Why working quickly is more important than it
| seems_ - https://news.ycombinator.com/item?id=10020827 - Aug 2015
| (139 comments)
|
| _Speed matters: Why working quickly is more important than it
| seems (2015)_ - https://news.ycombinator.com/item?id=20611539 -
| Aug 2019 (172 comments)
| snapcaster wrote:
| Site not loading for me :(
| michalstanko wrote:
| I guess the author did the website too quickly.
| havnagiggle wrote:
| Have you tried loading it faster?
| tobr wrote:
| Which is a little ironic considering this quote from the
| article:
|
| > It's now well known on the web that slow server response
| times drive users away. A slow website feels broken.
| paulddraper wrote:
| I was just about to give up when it finally loaded
| szczepano wrote:
| When I read about speed of doing things this always reminds me a
| tale of two programmers
| https://news.ycombinator.com/item?id=677655, archive link
| https://web.archive.org/web/20121226223216/http://mail.linux...
|
| I'm not against or in favour of speed. History showed us many
| times that most people don't care about truth and correct
| solutions, people care about efficiency and moving things fast.
| Just look at gaming industry and preordering. Agile project
| management. This is what is called taking risks and making a jump
| into abbyss before we look what is underneeth. Taking risk is
| always praised. Question is which jump will be last one and will
| kill us all?
| tabtab wrote:
| The CRUD IDE/Stacks of the late 90's were closer to the domain
| and that was a large reason for the productivity I used to see:
| more done with less key/mouse-strokes and less code. Web stacks
| make one waste time fiddling with janky stack parts & layers
| instead of domain logic, where it SHOULD be spent.
|
| It's hard to match their productivity with current web stacks,
| often requiring specialists and/or big learning curves. (Sure,
| the 90's IDE's had their warts, but were getting better with
| time, until web murdered them. And I'll limit this to small-and-
| medium apps rather than enterprise/web-scale.)
|
| It's usually assumed the features that made them productive are
| mutually exclusive with web-ness. I'm not convinced; the industry
| just stopped experimenting. What would help is a state-ful GUI
| markup standard so that GUI's don't have to be re-re-reinvented
| via HTML/DOM/JS, which is inherently ill-suited for rich CRUD
| GUIs.
|
| Having your language/tools/standards being a close fit to the
| domain matters. It's why COBOL lives on despite being even older
| than me. I'm not saying we should mirror COBOL as-is, only that
| it still carries important lessons, including FDD: Fit the Damned
| Domain.
| byteware wrote:
| "If you work quickly, the cost of doing something new will seem
| lower in your mind. So you'll be inclined to do more." well if it
| is work that I know I can do quickly I'm just gonna procrastinate
| the hell out of it, if it is something I enjoy doing I am already
| inclined to do it
| dmbche wrote:
| Just a note : I've noticed that when working with management,
| they often have issues "grokking" the issues they are asking for
| you to solve.
|
| By offering an imprefect, quick solution, it lets them understand
| the issue and readjust their needs in consequence - and often,
| the quick imprefect solution is good enough/enough work to show
| it's a bad idea and to move on.
|
| When starting project I have 2 steps : vomitting and touching up.
| You puke out a solution(minimum viable product), without thought
| about optimisation. When that exists, you change hats and
| optimise. Works wonders.
| Culonavirus wrote:
| Except the reality often looks like:
|
| > You puke out a solution(minimum viable product), without
| thought about optimisation.
|
| And that's where it ends, because unless your employer vastly
| overhired, there's already a dozen (or more...) of tasks in the
| backlog just waiting for you to vomit them out as well.
|
| After a year or two of working like this, you have a mountain
| of technical debt and no time work on it all. The entire system
| slowly disintegrates under its own weight.
|
| There needs to be a balance between fast and correct, and it is
| only up to the developer to resist the pressure from management
| to work fast (at the expense of correctness). I would go as far
| as to say that it is one of your main non-technical duties as a
| developer to resist and manage this pressure as best as you
| can.
|
| Maybe you're a genius who can analyze problems and implement
| solutions both fast AND correctly, but that is very rare.
|
| The truth is that complex problem solutions can have complex,
| messy implementations. They can also have simple, beautiful
| implementations. Or anything in between. But what they almost
| invariably require is complex investigations... which take time
| to conduct properly.
|
| Most (not all!) "fast" programmers I've worked with over the
| last 15 years produced output of questionable quality, often
| stemming from the "what you don't know you don't know" part of
| the knowledge pie chart, instead of some deeply thought out
| cost/benefit calculation.
| hgsgm wrote:
| The customer is always right about what they want.
| georgeburdell wrote:
| IME fast programmers are great at externalizing their QA
| whstl wrote:
| And in mine, slow ones are often even better.
|
| As much as we want to pretend that slowness correlates with
| attention to detail and quality of code, this is often only
| rationalization. Some people are perfectionists (in a bad
| way) and overcomplicate things that don't really matter to
| the end result, others have analysis paralysis and take too
| long to make decisions, making the code suffer, and others
| are just not that great and generate the same result as a
| faster developer at best. There are surely good but slow
| developers, but it's not as common as "internet common
| sense" paints it.
| iamcasen wrote:
| IMO if the code sticks around long enough to disintegrate
| under its own weight, than that code was a rousing success!
|
| "Resisting management" is almost always a horrible idea. Code
| is only useful when it provides a solution at the right time
| for the right price. If not, it is no longer useful and the
| world moves on.
|
| Overall quality is nothing more than a reflection of business
| maturity. Like a mighty old tree with a great big trunk. It
| has had time to grow strong and majestic.
|
| Most businesses don't live longer than 5 years. Most products
| and solutions are temporary fixes or ideas that don't last
| longer than a few months. Investing huge amounts of time and
| resources into those things is a recipe for disaster.
| mxmbrb wrote:
| I think this depends strongly on your companies bussines
| area. If you have BB with companies really relying on your
| product and long running contracts, the customer wants what
| he paid for. Including support for the heap of defects.
| Worse if you got a reputation to uphold and also want to
| keep your BB costumers. You can quickly become deadlocked
| in maintaining your old quick shots, unable to move
| anywhere. I think it is hard to make general rules without
| specific market context.
| bredren wrote:
| (2015)
|
| https://archive.is/2019.08.06-012000/http://jsomers.net/blog...
| maerF0x0 wrote:
| When folks speak hypothetically about speed, they almost always
| assume identical outputs. Which is pretty contrary to at least my
| experience, if not reality.
|
| Apple is the worlds most valuable company, and they're first and
| fastest in essentially nothing. So it really depends on the
| market you're going after.
|
| Anecdotally, (and backed by language learning research iirc),
| when learning is involved iterations are important. Learn a
| little, practice a little, get feedback a little, repeat
| frequently.
|
| But afaik it all comes down to the cost of failure. Public
| iteration on your encryption algorithm that's guarding billions
| of dollars is probably a bad idea.
| xrd wrote:
| Nice article. This is basically in the article when they talk
| about email responses back and forth, but not explicitly called
| out: if you are fast, people that interact with you get faster,
| too. Toyota figured this out with kanban
| (https://en.wikipedia.org/wiki/Kanban) and revolutionized process
| thinking. So, if you are thinking about how to get your team to
| work faster, focus on what is making slow team members go slowly.
| sashank_1509 wrote:
| Consistently I see this advice from everyone who I consider has
| achieved outside success in their field.
|
| Greg Brockman (OpenAI Cofounder) : Developer Speed is the most
| important thing I care about:
| (https://www.youtube.com/watch?v=CqiL5QQnN64). I believe he said
| more about this topic but I can't find it now.
|
| Frank Slootman (Snowflake CEO): In his book Amp It Up, he
| stresses why pushing people to move fast is extremely important
|
| Elon Musk (Let's not get into a debate about Elon and just agree
| that he has helped setup 2 100bn+ companies) : "I believe in
| maniacal sense of urgency, if you can implement something right
| after the meeting, do that", upon his work philosophy when taking
| over twitter.
|
| In my personal experience one of the most impressive coders I
| met, worked extremely fast while also being very accurate, almost
| indicating that no tradeoff even exists.
| painted-now wrote:
| Being fast and iterating reminds me so much of the EM algorithm.
|
| Probably a bit of a stretch but still:
|
| You start with an initial estimate of the hidden variables
| (solution), check what the consequences are by implementing it,
| and apply the knowledge about the right consequences to improve
| the solution.
| [deleted]
| flkiwi wrote:
| Aside from this post ultimately seeming like a bit of a joke
| given its conclusion, I found myself reflecting on a few things:
|
| - Prompting people to send me MORE email is a horrifying thought
| and set me right off thinking this would be a parody piece. -
| He's write that writing quickly can lead to more ideas. But if
| I'm writing for someone else, "quickly" can have multiple
| meanings: I can write one thing quickly, then have to rewrite it
| several times quickly to remedy all the assumptions and missing
| concepts even a competently, cleanly, and professionally written
| piece of text will have, OR I can slow down, answer all those
| questions as I go, and effectively write once well. Slowing down
| has been the best writing skill I've ever found for professional
| writing.
|
| - Having a straight brain-to-Google interface appropriate for
| 2015 described as permitting almost impulsive thought is ...
| scary. Discipline benefits even creativity.
|
| - I couldn't help thinking that this piece could have been simply
| "Work at a comfortable pace, and work on a single item, and don't
| get distracted by the world" and been more beneficial than "work
| quickly" (though, again, defining "quickly" is tricky).
| alexfromapex wrote:
| Compensation plays a big role in how fast I'm willing to get
| something done
| ukuina wrote:
| Doesn't compensation follow good/fast work, not precede it?
| TinyRick wrote:
| That has not been my experience in modern corporate America.
| garrickvanburen wrote:
| From my perspective - speed is about 2 things: more smaller
| iterations, confirming you're working toward a desired outcome.
|
| Over my career, I've been surprised multiple times when I
| presented early draft to a stakeholder and they said, "oh, that's
| great, I've got what I need now"...and this was maybe 1/3 of the
| effort I was planning for.
|
| The way I see it, if the problem is important - any early
| solution should provide some relief. If some initial relief isn't
| wanted, the problem is probably not important.
|
| Along these lines, in my work with stuck startup founders, I
| often ask, "if we were going to demo a prototype to a customer
| (in 2 days | at the end of the week), what would it be?"
| Zetice wrote:
| I cannot possibly emphasize this more strongly. It's _so_
| important to deliver complete and working products quickly and
| regularly, that it 's worth the cost of the occasional lost
| customer who leaves because all of their needs aren't met
| immediately. A) they're rarer than people seem to think and, B)
| the people you _gain_ due to this incremental approach more
| than cover the losses.
|
| That said, some devs interpret "quick" to mean "sloppy", which
| is not correct. When you can cut releases hourly the cost of
| some kinds of bugs does go down, but fewer bugs is better, and
| as always some categories of bugs are, "never, ever" (e.g. data
| corruption/leak, security bugs, outage inducing bugs).
| hinkley wrote:
| With a good sales team, you can land customers who don't see
| all the features they need, because you're routinely
| delivering a solid if simple product that gets major new
| functionality a few times a year and if you just hold on we
| will get your feature to the top of the list.
|
| Those paying customers are where your MRR comes from. Another
| case of perfect being the enemy of good.
| aeternum wrote:
| There is high overlap between customers who leave because
| their needs aren't met immediately and customers whos needs
| will never be met.
| afarrell wrote:
| To go fast, stay humble and use boring technology.
| andai wrote:
| I agree completely. That sounds much better than my current
| strategy of delivering incomplete and broken products at
| unpredictable intervals.
| EliRivers wrote:
| My highly specialised sarcasm sensors (honed in the UK)
| suggest that this is not in fact your current deliberate
| strategy; that said, I have worked for so many groups and
| companies where that is exactly what happens, even if they
| think they're planning for something else to happen, and
| it's obvious to pretty much everyone involved that that is
| what is happening and will keep happening.
| andai wrote:
| I was being humorous, but also telling the truth!
|
| I went straight from hobby programming to freelancing, so
| I've been "rediscovering" best practices the hard way.
|
| I did actually intend to do things properly, but client
| asked "can it be done faster" and I thought "sure I'll
| just ship fast and then rewrite it later"... ha! Project
| became so unmaintainable, development ground to a halt.
| (I am doing the rewrite now...)
|
| Turns out sometimes my job is to say "no."
| steve_adams_86 wrote:
| This is the side of software where soft skills are
| critical. Navigating when and how to say no can be
| extremely difficult, but it's arguably crucial to
| operating effectively and sustainably.
|
| Early in my career, everything was a yes and it cost me a
| lot of sanity. It rarely cost me clients because I was so
| diligent about keeping things on the rails, but that
| seemed to come with an inversely proportional cost to my
| well-being.
|
| It took me a long time to realize that saying no is kind
| of like saying yes; you're saying yes to getting the
| project done on a reasonable timeline and with the budget
| the client has, and most importantly, with your happiness
| intact. Saying yes at the wrong time can be saying no to
| finishing the project at all. It's the right, and in a
| sense "nice" thing to do for everyone involved.
|
| If you're a chronic people pleaser, this kind of work can
| be extremely taxing (speaking from experience).
| renewiltord wrote:
| As I always tell my team: fast, cheap, good; pick three.
| Eddy_Viscosity2 wrote:
| In my work they say: fast, cheap, good -- you can't have
| any of these.
| bell-cot wrote:
| Oncology?
| dmoy wrote:
| Or defense contracting?
| marcosdumay wrote:
| Well, that's my main strategy for my personal projects.
| collenjones wrote:
| Thanks. Hot coffee just came out of my nose.
| tome wrote:
| More to the point, it's much better than delivering
| incomplete yet working products quickly and regularly,
| complete yet broken products quickly and regularly,
| complete and working products slowly and regularly or
| complete and working products quickly and irregularly.
| greesil wrote:
| But why can't you just do it faster?
| gedy wrote:
| > That said, some devs interpret "quick" to mean "sloppy",
| which is not correct.
|
| Totally agree, but I've seen some devs completely melt when
| we need to go fast/iterate. For them, they really do produce
| sloppy work when they go too quickly. Many "big thinker"
| types are like this. Not defending it, just an observation.
| PartiallyTyped wrote:
| > The way I see it, if the problem is important - any early
| solution should provide some relief. If some initial relief
| isn't wanted, the problem is probably not important.
|
| I experienced this today, just now. The whole org's release for
| fall was hinging on what I was proposed... the relief of
| everyone once the presentation was over and it all clicked,
| when they saw the light at the end of the tunnel, that the path
| that I had uncovered towards that is reasonable, and tenable is
| priceless.
|
| I understand now that I live for this shit. 10/10 would do it
| again and again and again.
| boplicity wrote:
| As a customer of startups, I really abhor this attitude.
| Especially when it lingers for _years_ after the initial
| product launch. Which is _shockingly_ common.
|
| For example, partially complete features are often _completely
| abandoned_ for years and years, because they 're "good enough."
| Unfortunately, good enough, often means unhappy customers
| actively looking for new competitors.
|
| One company in particular, I absolutely despise, because of
| this. They are pretty much only focused on releasing new
| features. The old features, while functional, are in desperate
| need of improvement. (In many very obvious ways.)
|
| This particular company had a good IPO. Their stock then
| dropped 90%. I wonder why.
| jrochkind1 wrote:
| > They are pretty much only focused on releasing new
| features.
|
| My guess is that behavior is NOT motivated by the theory
| "deliver early drafts with more smaller iterations", but is
| instead motivated by the theory "the people who decide to buy
| our products do it based on feature checklists, rather than
| quality of anything."
|
| These are actually not even aligned theories. The "smaller
| iterations with early drafts" appraoch is best done with
| _fewer_ features included, not more features that are
| incomplete.
|
| Many markets incentivize companies to deliver crappy
| software, and it is frustrating, but not, I think the fault
| of an agile/iterative/deliver-early-and-often approach. If
| you can make the most money by delivering a giant feature
| list of crappily implemented poorly-thought out features that
| don't fit well together, you'll tend to do that, regardless
| of theory of project management.
| mvdtnz wrote:
| > Unfortunately, good enough, often means unhappy customers
| actively looking for new competitors.
|
| Here's the thing though - it's your intuition that customers
| are unhappy, but the startup in question has actual data.
| It's entirely possible that a small group of people similar
| to you are unhappy but for a majority of the userbase the
| feature has gone as far as it needs to. Resources are scarce
| and priorities need to be changed, which sometimes means
| making hard decisions.
| projectazorian wrote:
| Having the data isn't enough; someone also needs to look at
| the data and draw conclusions. If it's an environment
| focused on pumping up metrics for the newest thing then
| this may not be happening.
| yjftsjthsd-h wrote:
| We don't know that, actually; you _assume_ that the company
| has the data, and speculate that they interpret it
| correctly. But in practice, "customer loves using the app"
| and "customer puts up with the app but will replace it as
| soon as they find anything else" look the same right up
| until they don't, just as "high interaction" presents the
| same data as "app is disorganized and inefficient".
| Retric wrote:
| Alternatively, the rapid failure after IPO is a suggestion
| that their customers weren't happy, but the plan was short
| term pump and dump.
|
| It's not always easy to say if something is stupid or
| fraudulent, but sometimes it really is just a scam.
| sanderjd wrote:
| I find it so weird to look at the stock market to
| approximate this kind of metric. Stock prices have more
| to do with things like the ebb and flow of the risk
| profile of institutional investors, than with customer
| satisfaction with specific features.
| mvdtnz wrote:
| We'd need a lot more information about this one
| particular case but I'd bet almost anything that a 90%
| drop in share price was caused by something a lot deeper
| than customers being unhappy at some unfinished features.
| I intentionally didn't address that half of his comment
| for that reason.
| Retric wrote:
| That's reasonable, though I am not suggesting a pump and
| dump is only going to show up in the code base just that
| it would also look like they described.
| dkarl wrote:
| It's interesting that people almost never disagree with this
| when they're the customers. We love seeing progress, even if
| it's a small portion of what we need. When frequent updates
| show that progress is slow, we're glad we're aware, and we
| don't blame the updates themselves for slowing the project
| down. In the rare cases where we feel like the process demands
| too much of our attention, we don't stress about it; we just
| say, "Looks great. Let's talk again in two weeks or when you
| have completed feature X."
|
| Those hypothetical drawbacks only loom large in our minds when
| we're the ones doing the work.
| kubanczyk wrote:
| What about those invisible people who gave it a try and
| decided there were just too many gaps and bugs? They are not
| customers anymore and probably never will be.
| boredemployee wrote:
| I wish the PO of my team read it.
|
| He is so insecure to talk to customers and iterate with them
| that it gets on my nerves.
|
| He always have an ideal of "finished work" that, very often, we
| end delivering something not finished and/or wrong because we
| didn't iterate enough.
|
| Customers not always know what they want even though they say
| that they know what they want.
| cbhl wrote:
| If they find the appeal to authority useful, I'd grab them a
| copy of _Software Engineering at Google_ and leave them a
| bookmark in "Help Me Hide My Code".
|
| You can find the text here:
|
| https://abseil.io/resources/swe-
| book/html/ch02.html#help_me_...
|
| (disclaimer: work there, but wasn't involved in the book at
| all)
| ojbyrne wrote:
| I once worked on a team, in house at a company, where we were
| tasked with developing a prototype, in a scripting language
| with a well-known web framework. Meanwhile another team at a
| consulting company, was tasked with developing the final
| product in java, all very enterprise.
|
| The outside company ended up with a failed project, missing
| deadlines and going over budget multiple times. The prototype
| became the product.
| vsareto wrote:
| >The outside company ended up with a failed project, missing
| deadlines and going over budget multiple times. The prototype
| became the product.
|
| Getting paid to fail is a decent second place prize
| Ixiaus wrote:
| I really like the framing of "providing relief". I think it
| also makes sense to allow the definition of _who_ experiences
| the relief to be flexible (e.g in some cases the audience that
| experiences relief might be developers, security engineering,
| sre, etc. not just customers...)
| 0xbadcafebee wrote:
| From a DevOps perspective, speed is often the indicator that
| you're doing things right. If you integrate code quickly and
| often, if you deploy quickly and often, if you patch and upgrade
| software quickly and often, if you detect, diagnose and fix
| issues quickly and often, those are all indicators of a high-
| performing team. Quality isn't always correlated, but high-
| performing teams tend to care about quality, so it's not uncommon
| to add quality improvements to the list if you're doing
| everything else.
| tstrimple wrote:
| We tend to get better at the things we do often. Companies
| which have annual release cycles are almost always terrible at
| actually shipping software in my experience. One of my first
| goals in any new organization is improving iteration / feedback
| cycle speed.
| sublinear wrote:
| As the article states, this only works for stuff that can be
| broken up into low effort chunks. Not everything is like that
| such as maintaining legacy systems or working with large teams.
| :)
| commandlinefan wrote:
| > Not everything is like that
|
| In fact, almost nothing that's actually _useful_ is. Anything
| that can be broken up into predictable low effort chunks is
| something that can be automated away.
| danielmarkbruce wrote:
| I don't think he says predictable or low effort. Obviously
| you can't build and release a bridge in a week, nor a big
| software system. But you can still push yourself to move fast
| (a relative term), and these projects do in fact get broken
| down into steps, even if you can't predict all the steps from
| here to there, and even if you can't release something along
| the way.
| vsareto wrote:
| Or don't automate it and enjoy the extra slack time
| 0xbadcafebee wrote:
| If you can automate away programming, there's some people who
| would like to give you a lot of money.
| sublinear wrote:
| I don't think that's what the parent to your comment was
| about.
|
| You can't automate away programming, but you can write one
| program that behaves equivalent to many that accepts
| configuration from people who don't know how to program.
| aleph_minus_one wrote:
| > If you can automate away programming, there's some people
| who would like to give you a lot of money.
|
| A lot of the work that programmers do (which is not
| identical, but somewhat related to "a lot of programming")
| could be left out (which is not identical, but somewhat
| related to "automated"). The reason is that a lot of
| programming is working around the gigantic brokenness of
| the whole software ecosystem. Here there does exist an
| insane amount of possible cost savings.
|
| Concerning the "some people who would like to give you a
| lot of money": I actually talked about my thoughts with a
| friend who knows a lot both about economy (he works as a
| business consultant) and programming. He clearly said that
| my ideas on this topic were really smart and thought
| through, but getting money is a lot more complicated (it
| demands both being a good salesman and having connections).
| So "some people who would like to give you a lot of money"
| is simply not true. :-(
| sublinear wrote:
| > gigantic brokenness of the whole software ecosystem
|
| If you mean the employing organization and its ignorance,
| I agree. For most organizations today, their value is
| locked up in technology and those who maintain it. The
| rest of the business (non-technical people) are
| essentially overpaid punching bags for everyone to smack
| around. In an ideal world programming would not be a
| special skill, but just another means of communication.
| CatWChainsaw wrote:
| I doubt whatever severance they get can last them the rest
| of their lives.
| hgsgm wrote:
| It's not 1 severance, it's 1 million.
| CatWChainsaw wrote:
| Unless one person is getting one million severances,
| they'll outlive it.
| Sakos wrote:
| As somebody who works with legacy systems, it might take me a
| while to understand everything, but I think being able to
| experiment with different solutions rapidly is incredibly
| useful and has helped me zero in on the best possible solution
| considering the constraints. It also helps in understanding how
| the system works on a deeper level that often isn't possible
| just by reading code. Sometimes you just have to break things
| while implementing a possible solution.
| [deleted]
| andai wrote:
| https://archive.ph/jl4oc
| agentultra wrote:
| I wonder how the author thinks about this now, 8 years later.
|
| Way back in 2016/2017 I saw this video on prototyping where the
| programmer whipped up a snake clone in around 4 minutes. I
| deliberately practised programming in this way: how fast can I go
| from idea to working prototype? Code style, organization,
| testing, best practices be damned: you have about how long it
| takes to run a load of laundry, how much can you get done?
|
| I did this for a few months. I focused on games. I roughly
| tracked how much time it took to get from empty file to the first
| interaction with the game. I tried to focus my practice on
| getting to that first interaction. And the overall time I spent
| and how far I got with the idea.
|
| The thing with going that fast is... the code sucks. You're not
| writing it for an audience, for your future self, to make it
| possible to extend and compose; when you want to go fast and
| prototype in this way you're deliberately not going to use this
| code for anything later on. You just want to get the idea out
| there to see, "is this even fun? Would it even work at all?"
|
| ... before you go ahead and spend the next 6 - 12 months spending
| your limited time on something. Because finding out your game
| isn't actually fun after all of that effort is demotivating.
|
| In this sense speed is useful. It's useful in certain contexts
| when doing programming on the job. Especially at startups where
| the runway is limited and you don't know if you even have
| customers yet.
|
| However!
|
| Be prepared to throw it out. Once you find some traction for a
| feature or process; throw out the prototype/MVP code. Make sure
| it's cheap to do that: you can write software that is loosely
| coupled, you can write a better API that uses the MVP code
| underneath, write good tests against the new interface, remove
| the old code paths piece by piece, etc. If it's a core part of
| the product and there are customers for it get rid of that
| prototype/MVP code some how (it's easier to plan for this and not
| get too attached to the first iteration if you do it
| intentionally).
| syntheweave wrote:
| Agreed - There's a certain thing about greenfield development
| in particular(which is quite fully the realm of startup coding)
| where you have to approach the first, second, maybe third
| iteration as one that will be thrown away, so when it does get
| thrown away, you make it easy to do so. And that leads towards
| some pretty dumb code, often "copy-paste-modify, sort it out
| later" code.
|
| A lot of "best practice" ideas that get made into blogposts
| impose a structure that hinders disposability in favor of a
| certain aesthetic goal: to do the thing with less repetition
| and slightly cleaner abstractions. The goal is often not
| unreasonable, but it conflicts with the action of rapid
| iteration.
|
| So I tend to write now with an eye towards trying to keep the
| code disposable until I face a certain class of error to
| eliminate, that needs the more abstract method. Often part of
| the disposability is in not actually solving the entire
| problem, but cheating and returning a wrong answer, e.g:
|
| Instead of fancyAlgorithm() being written in a way that creates
| any dependencies I write a skeleton "function fancyAlgorithm()
| {return true;}" and then later upgrade it to a lookup table,
| and then to the algorithm. Because most of the code that
| matters to the app won't be in the algorithm, but in how all
| the other data is being passed around. The sooner I can get
| that piece to return a wrong answer with known error, the
| sooner I can arrive at a complete but wrong app, which can be
| corrected into a higher quality one. When not all the pieces of
| the app are there, it's not clear what error you need to be
| solving for, which leads to squeezing effort onto code that
| isn't important.
| bern4444 wrote:
| Speed matters when the thing being built is isolated.
|
| If you're building a new feature/product whatever, and the
| business views that both as a standalone feature, but also as a
| stepping stone to support another product or feature then the
| code you get when writing quickly is going to slow you down in
| that next step.
|
| Scale that up a few levels and you end up with 'enterprise code'
| that no one wants to touch for fear of breaking all the parts
| that depend on the pieces below it.
|
| So write code quickly when its isolated and not planned for use
| in additional products, features, capabilities.
|
| It is very difficult to convince management to prioritize tech
| debt and the only successful way is in the frame of enabling
| additional product capabilities.
| hot_gril wrote:
| If you're building a stepping stone, you still have to figure
| out how to make it isolated in a way then do it quickly. Like
| if it's a software service, spend the extra time figuring out a
| good API then speed through the initial implementation.
| lars512 wrote:
| I think about this another way. If you're fast enough, you can
| afford to do the gardening you need to keep your codebase in a
| good way without having to schedule it all in. If you're fast
| enough, when doing data analysis, you earn the space to ask the
| next question, and the next, and to do a deeper analysis.
|
| But... as a lead, I've struggled to train speed before. Some
| people I've worked with have had it, junior or senior, and some
| have not.
|
| Has anyone had good experience helping others become faster at
| their work?
| iamcasen wrote:
| No. I think humans are all unique. Just like a pro basketball
| coach, you are looking for the right talent for your particular
| team and your particular context.
|
| I have had extremely smart, talented, thorough engineers who
| are slower than whale shit in an ice flow. For a startup, those
| engineers are a death sentence. It doesn't matter how good they
| are, if they aren't fast, they hold everyone back.
|
| Are you building the roman empire, or are you building a small
| group of bandits that move swiftly through the night? Each case
| has it's corresponding strategy.
| m463 wrote:
| To a point. burnout matters too. If creating emails quickly leads
| to quick replies and more emails, before you know it you've
| emailed to your exhaustion point.
|
| this is a tactic and strategy matters too. speed matters on
| things that matter.
| ed wrote:
| https://web.archive.org/web/20230602051336/http://jsomers.ne...
| jmclnx wrote:
| When it comes to business (corporate), you hear "do it right".
| But in reality that means "do it fast even if wrong". If mistakes
| are made, what happens depends upon management.
|
| In most cases, I have seen people who do a project 100% correct,
| sometimes slightly slower get ignored.
|
| Other people who get it done fast, even with many blaring
| mistakes, get rewarded. Usually the people who worked on it end
| up working 24/7 to get it fixed. That is looked upon by most
| managers as very good work.
|
| If your projects go live without issues, it is usually forgotten,
| people who fix their own issues by putting in fixes after go-live
| by working 24 hours, get noticed and rewarded.
| aeternum wrote:
| The fact of the matter is unless your company is very mature,
| getting 3 big features to prod in a month even if that means
| bringing down some system for awhile is generally much more
| valuable than getting a single feature out with zero downtime.
|
| As the company and number of devs grow, the probability of a
| dev doing something stupid increases substantially, so those
| early mistakes can actually be quite valuable in showing where
| your infrastructure has gaps.
|
| Let the imperfect code happen early, it often leads to free
| chaos-testing and more stable infrastructure.
| inconceivable wrote:
| graphic designers sometimes ship their draft deliverables with
| 1 or 2 obvious bugs, and allow the customer to recommend these
| 'changes' on their own for final delivery. and if they don't,
| they're just fixed for final delivery anyway.
|
| i read about it before i had this done to me for the first
| time, and i played along with it. it's a neat trick because
| it's plausibly deniable for everyone involved and the outcome
| is good while minimizing the bullshit work in favor of a
| sacrificial final word.
| garrickvanburen wrote:
| I've also done this, with both visual design and software.
|
| It's a deliberate canary - if the client didn't comment on
| the obvious mistake/bug, I know they didn't actually look at
| it.
| politician wrote:
| There is a concept of a sacrificial feature to prevent
| customers from becoming fixated on other aspects of the
| design that would actually create problems if changed. I
| prefer to avoid that sort of dark pattern though because it
| erodes trust.
| Graffur wrote:
| Agreed. In the same vein I have seen this approach work well
| too: "make the issue a big deal, then be the hero that fixes
| it"
|
| If you just fix it business as usual.. or prevent the issue
| then noone will care about you.
| painted-now wrote:
| How can you distinguish between "project is not
| important/forgotten and due to that, no issues are discovered"
| and "there are no issues, so it is forgotten"?
| maerF0x0 wrote:
| I encountered this in a previous job. I told them during
| design phase the implementation was failing basic computer
| science knowledge and would cost the company a lot of excess
| computing costs (due to redundant work).
|
| a quarter after launch it was a crisis because $5k a month
| customers were costing $50k a month in compute. The original
| designer put in some patches that got it down to $25k, and
| then $3k and was a "hero". By my estimates the limit of the
| actual work being done should have been < $500. But we didn't
| have time to implement that due to a quarterly insistence and
| folks all nodding their heads at eachother to get promoted.
|
| In the end he got promoted and i got a negative review for
| not being a "team player" (ie being disagreeable about a
| design I knew had undesirable properties)
| hgsgm wrote:
| > told them it was failing basic computer science knowledge
|
| > i got a negative review for not being a "team player"
|
| Effective communication is good for your career. People
| don't want to work with someone who slings distracting
| insults.
|
| You can say "This will cost $50K, but we can't afford more
| than $5K, and I think we can do it $500", or "a 10x
| customer will cost 100x to serve, but a different design
| can bring that down to 10x".
|
| SaaS without the sass.
| maerF0x0 wrote:
| you're not wrong in general, but wrong about my demeanor
| in this case.
|
| Team player meant a lot of head nodding, and making each
| other look great in a previous company.
___________________________________________________________________
(page generated 2023-06-13 23:01 UTC)