[HN Gopher] I could do that in a weekend (2016)
___________________________________________________________________
I could do that in a weekend (2016)
Author : spiffytech
Score : 165 points
Date : 2020-04-29 14:41 UTC (8 hours ago)
(HTM) web link (danluu.com)
(TXT) w3m dump (danluu.com)
| renewiltord wrote:
| The community solved this generations ago with one phrase: "Talk
| is cheap. Show me the code."
|
| I guess now that we know it's more than just the program, the
| startup adage equivalent is "Talk is cheap. Show me the product."
| ascendantlogic wrote:
| There's always two things that these armchair quarterback
| software devs seem to miss: Scale and Money.
|
| Sure you can hack together a small Google clone using
| Elasticsearch in a weekend. Can you index all the worlds
| information and serve the worlds search needs with your little
| MVP? 99.99% chance no, even if you were given a few hundred
| engineers to scale it.
|
| Even if you could do it technically, where are you coming up with
| the money to do so? That's not seed-round or even series A round
| money to do that. That's series D, hundred+ million dollar swipes
| of a VC's credit card just to get off the ground. Microsoft threw
| billions at it with Bing and still never became more than an
| also-ran. The only place that seems to have a real chance is
| DuckDuckGo, and I'd be very interested to see how their story has
| played out up to this point.
|
| Google benefited greatly from growing as the web was growing.
| Trying to index the world's information in 2020 is an
| astronomical task compared to indexing the world's information in
| 98, 99 era.
| 3pt14159 wrote:
| Bing was my secret weapon when doing data science contracts
| that were MVPs or side features.
|
| Take a couple million preselected strings they needed to match
| to and then run them through Bing, page through the results,
| and build up the corpus I needed out of something like
| mechanize / nokogiri / headless browser.[0] Then clean up the
| data the normal data science way then do whatever mathy stuff I
| needed to layer on for whatever app they needed. There you go
| mister client something that has billions of dollars of R&D
| behind it and cleaned up for your specific use-case. You want
| something better? Go off and hire a team of Phds and spend a
| couple years and 50x the money I charged you to get your RoC
| curves (or whatever) looking 10% or 15% better.
|
| Haven't done this in a couple years due to a startup and then
| after that randomly finding a client I liked working with so
| much I haven't needed to take on random jobs again, but I'm
| sure it would still work.
|
| [0] I had also written custom tools to make this easier /
| saner. Also inspector gadget + CSS selectors goes a long way
| too.
| mettamage wrote:
| > Scale and Money
|
| This is too simple of an answer. By these metrics Google+ would
| be a success. Also, the total funding amound of DDG is 13M (see
| Crunchbase). While that is serious money, that's not series D
| money.
|
| Moreover, there are counterexamples of companies that did build
| an app in a relatively short amount of time, kept a small team
| and made millions per employee. I don't know of many [1], but I
| think WuFoo is an interesting example, founded in 2006 while
| SurveyMonkey was founded in 1999. WuFoo exited for 35 million
| in 2011 with a team of 9, I think (there's a YC YouTube video
| about this somewhere).
|
| Disclaimer: I'm an armchair quarterback.
|
| [1] I don't know of many tech companies in general.
| mrkeen wrote:
| > > Scale and Money
|
| > This is too simple of an answer
|
| Writer implied necessity, not sufficiency.
| mettamage wrote:
| I didn't see it, but if others did, then I stand corrected.
| astrea wrote:
| Google+ isn't a fair counter-example. From a technical
| perspective, it very well could've been. The failings of
| Google+ was social.
| drevil-v2 wrote:
| WhatsApp is another example. I believe it was 13(?)
| employees, $16 billion exit and close to a billion users
| worldwide
| mettamage wrote:
| Yea, also pretty small scale-wise, from what I've heard.
| pheug wrote:
| DDG is not in the index-all-the-web business. For the most
| part they are just serving Bing's results, that's the only
| reason why they operate with so little funding - it doesn't
| take much to operate a glorified proxy. Microsoft's footing
| the bills for the actual web search operation and I'm sure
| it's way above 13M.
| jonas21 wrote:
| > Microsoft threw billions at it with Bing and still never
| became more than an also-ran. The only place that seems to have
| a real chance is DuckDuckGo, and I'd be very interested to see
| how their story has played out up to this point.
|
| That's an interesting perspective when you consider that:
|
| 1. Bing has at least 5x the market share of DuckDuckGo in the
| US (and even higher worldwide)
|
| 2. DuckDuckGo uses Bing as its main source of search results.
| gustavo-fring wrote:
| I've been playing armchair QB for 20 years, my QBR is 91.
| Nobody is seriously saying index all of the world's information
| in a weekend. They're saying that the tech to index the web and
| otherwise has increased in the last 20 years, which enables you
| to do more. Google isn't even a great example, considering how
| intensive it is at scale. There are a lot of apps, especially
| with user created content, that don't have that issue at all.
| Your argument is the other end of I can build Google in a day,
| it dismisses criticism by making it absurd.
| kelnos wrote:
| The "I could build it in a weekend" is certainly one extreme,
| but I think even people who say "I could build Google in 3
| months" (or even 6 months, or a year), just don't get it.
|
| And yes, there _are_ actually a decent amount of people who
| say, literally, "I could build that in a weekend". Not sure
| how many people say that about _Google_ , specifically, but
| it comes up often enough. This post was also from 2016, and I
| do feel like it used to come up more often in years past than
| it does now.
| heavenlyblue wrote:
| Most of the people I know, who say "I could build that in a
| weekend" mean that they could build a product that solves
| 90% of the problems in that problem space in a weekend.
|
| And that's true. The other 10% is what gives you
| competitive advantage as a product.
|
| The truth is that _if_ the market was empty at the time;
| then those 90% would give you enough runway to finish the
| rest of the 10% with a certain high enoufh probability.
| a1369209993 wrote:
| I can't speak for anyone else, but as someone who has
| literally said that on several occasions, you've
| perfectly summarized ( 90% of :) ) what I generally mean.
| valachio wrote:
| The author's website is an example of a product that is "done in
| a weekend".
|
| It is very annoying to this post on a 28" monitor... the text
| runs from left to right with no margin spacing.
| PaulDavisThe1st wrote:
| browser > reader mode FTW! Really, it's that simple!
| XCSme wrote:
| I also couldn't read it on a 27" 4k monitor, just closed the
| site. I tried with zooming in, but it was still too much of a
| hastle.
| dpcan wrote:
| There's not even a <body> tag. It just has some header
| information and jumps right in to the text, but he took the
| time to add Google Analytics. It's so bizarre.
| robocat wrote:
| You do know that the <body> tag is optional in HTML5? From
| MDN: The <body> tag "may be omitted if the first thing inside
| it is not a space character, comment, <script> element or
| <style> element. The end tag may be omitted if the <body>
| element has contents or has a start tag, and is not
| immediately followed by a comment."
|
| However, in this particular case the body starts with a space
| character, so it should have a body tag.
|
| A minimal _valid_ HTML5 document looks like:
| <!doctype html> <meta charset=utf-8>
| <title>blah</title> <p>I'm the content
| _glass wrote:
| to be fair, I was relearning to just resize my window.
| wolfgke wrote:
| > It is very annoying to this post on a 28" monitor... the text
| runs from left to right with no margin spacing.
|
| Rotate your monitor by 90 degrees for a better reading
| experience. If this is not possible, buy one that can.
|
| Until it arrives, use the Reading View of your preferred
| browser.
| XCSme wrote:
| My monitor can roate 90 degrees, but I prefer it landscape,
| it's more ergonomic not to have to tilt your head vertically,
| your eyes are horizontal.
| clarry wrote:
| Do you actually do that?
|
| I've tried it. In portrait mode, my old 24" 16:10 monitor is
| already tall enough to wreck my neck and be really
| uncomfortable to read. I wouldn't even want to try that with
| my current 27" 16:9 monitor..
| dmart wrote:
| A certain set of people take enormous pride in using unstyled
| HTML like this. (See "Motherfucking Website" [0])
|
| The problem is it's not 1994 anymore, monitors are no longer
| 800 pixels wide, so it looks like shit and is impossible to
| read. It's well accepted that 70-90ish characters per line is
| best for readability, and instead now on an average monitor
| unstyled HTML gives you like 250.
|
| [0] https://motherfuckingwebsite.com/
| oxalorg wrote:
| I solve this problem using a bookmarklet [0] which
| automagically applies sane css to websites like these.
|
| It's insane that it's 2020 and some people still refuse to
| use CSS haha
|
| [0]: https://oxal.org/projects/sakura/bookmark
| zokier wrote:
| What is insane is that peoples user-agents do not format
| documents the way their users want.
| ryandrake wrote:
| Better than hardcoding some fixed or percentage width, leaving
| 5 inches of wasted blank space on the left and right side of
| the page, like many web sites do.
| suyjuris wrote:
| The author seems to have given this topic some thought [0].
|
| Personally, I did not experience any problems reading it on my
| ~50cm wide monitor.
|
| [0] https://twitter.com/danluu/status/1228041917272715264
| saagarjha wrote:
| I'm obligated to post a reminder that sometimes your team _is_
| horribly bloated or incompetent or your choice of technology is
| wrong, so make sure you 're actually doing useful things before
| feeling relieved that you're invincible. Sure, nobody is going to
| upend your business in a weekend, but there's been many, many
| examples of a company doing this and then someone working by
| themselves for a couple of months or years (usually, this is just
| someone who actually bothered to care enough to spend time on the
| problem) comes along and does far more than they thought was
| possible. Stay on your toes!
| bluedino wrote:
| People make the mistake of saying "I could build GMail in a
| weekend!", when they really mean, "I could build _a web-based
| email system_ in a weekend. "
| buboard wrote:
| This is overly simplistic. There is plenty of great services that
| can be done in a weekend. And some very elaborate engineering
| projects with tiny traffic. When people wonder "why they need so
| many programmers", sometimes they are right. They hired them to
| stop them from building competitors.
| chillacy wrote:
| > They hired them to stop them from building competitors
|
| If that were true, wouldn't you have to hire every developer
| who could possibly build your app in a weekend to succeed at
| that? It just takes one to start a new competitor.
|
| Building a new competitor is more than just a matter of code,
| there are often network effects, a lot of marketing, and often
| still a cost to switch from a less than optimal but good enough
| solution to an optimal one.
| buboard wrote:
| > every developer who could possibly build your app
|
| well haven't they? a competitor doesn't need to be a copycat.
| like how, e.g. google bought deepmind
| empath75 wrote:
| Most of the big sites _were_ built by a couple of coders in a few
| weekends. Google was online a few months after the page rank
| paper was published. Twitter took a small team a couple of months
| for the initial release. Zuckerberg famously wrote facebook in a
| couple of weekends.
|
| Most of the explosive growth of those companies was built on
| essentially weekend projects by a handful of coders, or even one
| person.
|
| You absolutely can write a billion dollar app in a weekend. If
| you have the right idea at the right time, with the right
| connections.
| amelius wrote:
| > But in the comments on Alex's posts, multiple people respond
| and say that Lucene basically does the same thing Google does and
| that Lucene is poised to surpass Google's capabilities in the
| next few years.
|
| Let's first build a benchmark. Without it, you're basically in
| the dark.
| gipp wrote:
| Well that's just reinforcing their point. Do you have any idea
| how much Google spends on creating some semblance of "search
| quality benchmarking" that actually means something? I'd
| venture it's way, way more than you imagine.
| dang wrote:
| Discussed at the time:
| https://news.ycombinator.com/item?id=12626314
| cwackerfuss wrote:
| A little line-height and content max-width could go a long way
| thelazydogsback wrote:
| No... Premature presentation is the root of all evil! :) This
| is content, not art.
| runawaybottle wrote:
| Yeah, plus, I should be able to view this page with
| JavaScript and my entire browser disabled/uninstalled.
| [deleted]
| codegeek wrote:
| I did this : body { max-width:
| 600px; margin: auto; line-height:
| 1.7em; }
|
| Much better :)
| kristiandupont wrote:
| Firefox reading mode. It saves me 2-3 times per day. Don't know
| how I ever lived without it!
| [deleted]
| scott_s wrote:
| Because the content is just simple HTML, it's amenable to the
| reader view option available in most browsers.
| benhurmarcel wrote:
| You can put some simple CSS and still leave the simple HTML
| available to be styled by the browser's reader mode.
| dwaltrip wrote:
| It should have a sane default. The current default
| presentation is not sane.
| clarry wrote:
| Your user agent should have a sane default. The idea that
| every text document on the web should ship their own
| default is insane.
| [deleted]
| 6gvONxR4sf7o wrote:
| I wonder about this as an efficiency thing. Instead of search,
| let's use a charity as an example. Why does XYZ charity need a
| zillion people? Why does it spend so much on TV ads? The answer
| tends to be that hiring more people and advertising more brings
| in more net dollars. You add and add until the marginal cost of
| another ad/hire/whatever matches the marginal gain. It makes
| total sense for the charity to do this, but as a potential donor,
| now less of your dollars go to the thing you care about and more
| go to admin, advertisers, etc. It's like friction in the system.
| To compete with you, now other people have to spend on ads, and
| the whole ecosystem is less efficient.
|
| I think there's an analogy here for for profit companies. Maybe
| if instead of adding a tiny marginal dollar for BigCo, you could
| add a big marginal dollar for SmallCo, and society's per capita
| productivity is lower? I can't pinpoint whether the analogy works
| for companies, but I suspect it does.
| dudul wrote:
| So yes. I'm a big fan of avoiding the hand waving and garbage
| like that when describing/specing a product's behavior. Features
| are always more complicated than the elevator pitch, there are
| edge cases, points of integration with the rest of the system,
| etc. So yes, things are almost always more complex than they
| appear.
|
| But also, no, I've definitely seen a lot of companies with an
| insane headcount simply to "do more in parallel" or "deal with
| the complexity of the system". Sometimes, having too many people
| to keep busy is really bad.
| lordnacho wrote:
| "except that when you talk to companies that handle their own
| billing, they can point to individual features that increase
| conversion by single or double digit percentages that they can't
| get from Stripe or Braintree"
|
| Kinda intrigued as to what that means? What features in the
| billing increase conversion by percentage points, but are not
| available via an outsourced payment provider like Stripe?
| heavenlyblue wrote:
| They lose customer data and then end up in newspapers.
| pazimzadeh wrote:
| Except that Google didn't become #1 by having better support for
| Arabic and Japanese than Yahoo/Lycos/Dogpile.
| jgwil2 wrote:
| Should be marked "(2016)"
| ineedasername wrote:
| I could have written this blog post in a weekend.
|
| (I know, downvotes incoming. Worth it)
| michaelbuckbee wrote:
| To OP's point of "features are more complicated than they appear"
| I always like to point to the flowchart of Slack's notification
| logic.
|
| https://pbs.twimg.com/media/C6ROe0mU0AEmpzz?format=jpg
| vsareto wrote:
| This is a luxury if you as a dev get handed something like
| this. If you're actually the one that has to make the flowchart
| by translating customer requests, it's clearly a lot harder.
| folmar wrote:
| It's convoluted because it's expressed in an incomprehensible
| way. Make it a Petri net or something, first decide what is the
| class of the message & pref of that class and it's 3x simpler.
| hyperpape wrote:
| Somewhat related: in spite of this complexity, Slack desktop is
| missing options in closely related functionality. The only way
| to avoid a visible badge appearing on a slack workspace is to
| sign out entirely, which lands you in the tire fire of trying
| to reauthenticate to a slack.
|
| So you can silence notifications, but unless you're good at
| ignoring those little red dots, you'll still be distracted.
| nickysielicki wrote:
| I like this one from ChromeOS about boot decisions.
|
| https://www.chromium.org/_/rsrc/1277241373652/chromium-os/ch...
| saagarjha wrote:
| This was actually less complicated that I had expected it to
| be.
| evfanknitram wrote:
| Yes, this is what my co-workers refer to as an if-statement.
| dudul wrote:
| This is not about how it translates into code. I see a lot
| of value in this diagram when compared to the half-assed
| "requirements" most PMs put in their JIRA tickets.
| lliamander wrote:
| I find myself creating a lot of these diagrams to share
| with PMs (along with sequence diagrams, system
| architecture diagrams, decision tables, etc.).
|
| Systematically articulating all of these different
| conditions isn't necessarily the strong suit of a PM, but
| they're generally quite capable of understanding and
| providing input to such documents.
| sethammons wrote:
| That is my takeaway: PMs and non-developers - you must
| think through the entire workflow. When you don't, your
| engineers will and will either pepper you with questions
| that you are not prepared for or they will decide for
| you.
| dudul wrote:
| I'm _exactly_ on the same page, this is uncanny!
| paxys wrote:
| All programming is just if statements. That doesn't mean
| systems can't be complex.
| a1369209993 wrote:
| Not true; if the conditional branch goes backward then
| it's a (possibly do-) while statement. Also subroutine
| calls.
| saagarjha wrote:
| I mean, the chart is still useful to have, and it'd be a
| couple of methods probably had I written it. But it's not a
| huge state space, and most of the transitions are fairly
| reasonable.
| Drdrdrq wrote:
| I can imagine it was quite a lot of work to come to such
| a clean and relatively simple chart.
| lliamander wrote:
| I think the example still works because, while it is not too
| complicated to understand, it is also non-trivial. It's also
| probably more complicated than the typical non-technical
| person would think.
|
| It's also worth mentioning that this diagram doesn't capture
| dataflow or the relationships between the subsystems needed
| to make this work. The logic for notifications requires
| interaction with user preferences, channel membership,
| comment parsing, thread management, and more[0].
|
| All told, you may still be looking at (low) thousands of
| lines of code, with maybe 1.5-2x times that amount for test
| code.
|
| [0] I'm just guessing how the app is structured internally. I
| have no idea what it is actually like.
| MichaelDickens wrote:
| Things like notifications have pressure on them to be simple,
| because users want to be able to decide when they will
| receive notifications, which means it needs to be easy for
| them to understand when they will and will not receive them
| with particular settings. I'm sure there are examples of some
| non-user-controlled decisions that have much more complicated
| flow charts.
| paxys wrote:
| It's also like 3 years old. Would love to see what it looks
| like now.
| folmar wrote:
| It's like never true, it does not show that you can't get
| email notification faster than in 30 minutes.
|
| Also now should include adding random old stuff to
| notification.
| nickff wrote:
| Yes, it was something I'd never thought of before, but
| definitely simpler than I guessed before I clicked the link.
| That said, each time you add a conditional, you need to be
| increasingly careful about where you put it, and what other
| impacts it has.
|
| I would also imagine that there are a variety of other
| features which require similar flow charts.
| phogster wrote:
| The "User in DnD?" box made me chuckle.
| pearjuice wrote:
| Do not disturb.
| hawkice wrote:
| For other readers (like me) who were confused for a few
| seconds (maybe because I don't use slack?): Do not Disturb.
| JoBrad wrote:
| Because they're playing Dungeons and Dragons.
| GuiA wrote:
| Nice. The fact that it can be described by a diagram that fits
| on a single screen and could be absorbed by a new hire in 20
| minutes is neat.
|
| I wonder if there are ways to design software such that we can
| get visualizations like this generated from the code "for
| free". It could definitely be really useful when diff'ing code,
| or even just for general communication in meetings etc...
|
| Perhaps there are some academic/esoteric languages that do
| things along those lines?
| gustavo-fring wrote:
| There is a lazy argument that ignores the difficulty and hard
| work of putting out not only a working but a good application
| out, but the other end of that is using Dan's argument (which is
| valid), to dismiss criticism.
|
| To wit, Google has 80k employees now, in 2010 it was at 10k and
| the number only drops as you go further back. I think it's pretty
| easy to say that Google was doing more impressive things at the
| beginning of the century, and certainly the climb was greater.
| Within the last five years, there was a moment when Google had 4
| competing chat apps. This is pretty rank inefficiency. If you
| were to take 80k people (not all are engineers, obviously) and
| sit them down and ask them to use their talents to build
| separately, you'd end up with a lot more innovation and
| productivity, I'm pretty certain of that.
|
| The entire point of a minimum viable product is not that you have
| a complete, flawless app, but rather that you get something up
| you can iterate on quickly. That can be built in a weekend (I'm a
| slow worker, but I know people that can do crazy stuff in a night
| and interest). My personal criticism (and something I'm testing),
| is that our current processes are not harnessing all the gains in
| productivity we've seen over the decades, nor the ability to do
| that because it is very cheap to do so is not happening on a
| large scale. It's not totally apparent why it is happening, but
| it isn't.
|
| I realized late that people take this criticism personally and
| feel like you're saying they are stupid or don't work hard or it
| is all so easy, but I ask you to consider the nature of our
| industry and how easy things are to build and then ask you why we
| don't see real competition across so many products.
|
| The moats of many companies are perceived. The goal isn't to
| build Google in a weekend, it's to take the first step and give
| yourself an opportunity.
|
| edit: my numbers are off, it's 25k to 100k
| quicklime wrote:
| Their 2010 revenue was $29.3 billion, and in the last four
| quarters (including the recent Q1 announcement) they raked in
| $166.71 billion. If your headcount numbers are correct, and
| they've gone from 25k to 100k employees, they've actually
| managed to increase their revenue faster than their headcount.
|
| Their constant failure to make a dent in the chat app space is
| surely embarrassing, but having a few parallel efforts is a
| drop in the bucket in terms of efficiency.
| BenderV wrote:
| Facebook have 2 successful chat apps (Whatsapp, Messenger)
| and 2 successful social networks (Facebook.com, Instagram)
| TulliusCicero wrote:
| One of those chat apps was already enormously successful
| and then Facebook just bought it. The other was a natural
| outgrowth of Facebook.com being a successful social
| network, you may as well claim that Instagram is also a
| successful chat app.
| Silhouette wrote:
| Small businesses innovate. Big businesses consolidate.
|
| Figuring out how to maintain a small business pace of
| innovation while achieving the consistency and economies of
| scale of a big business is basically the tech industry's quest
| for the holy grail.
| lowdose wrote:
| Isn't that exactly what Amazon is doing?
| Silhouette wrote:
| Sorry, I don't really see why.
|
| Amazon's big success stories recently have been about
| providing the infrastructure for other businesses, both in
| its retail storefront and with AWS. This is one of the
| tried and tested strategies for big businesses to exploit
| their greater resources while not actually having to do the
| grunt work to create new products or services that end
| customers are willing to pay for.
| lowdose wrote:
| Amazon is not a moonshot factory inside trying hundreds
| of ideas small & scale the successful big?
|
| You think AWS was planned ahead for years and everything
| that runs on top of it?
|
| If AWS was such a logical consolidation why has Amazon
| such a big market share of the cloud and can even Google
| & Microsoft barely catchup with the innovation?
|
| Did you ever speak to an engineer working at Amazon or is
| this some feeling you have??
|
| I talked to Werner a couple of times and everything he
| told me disputes your personal assumptions.
|
| The commoditization of logistic and compute
| infrastructure is real innovation although it looks like
| consolidation from the outside.
| Silhouette wrote:
| Amazon as a whole has nearly a million employees and
| generates 12-figure revenues. It would be remarkable if
| it had no R&D at all happening outside its main
| activities.
|
| But imagine if you could take the more capable people who
| work on Amazon's high-tech systems like AWS or logistics
| automation, bundle them into well-composed teams of a few
| people each, and give each team say $10M in funding.
| You've potentially just created more highly capable
| startups with enough runway to do something worthwhile
| than YC has funded in its entire history. Tell me with a
| straight face that Amazon as a whole is innovating as
| much as the combined portfolio of YC from day one.
| crazygringo wrote:
| > _I think it 's pretty easy to say that Google was doing more
| impressive things at the beginning of the century... Within the
| last five years, there was a moment when Google had 4 competing
| chat apps. This is pretty rank inefficiency. If you were to
| take 80k people (not all are engineers, obviously) and sit them
| down and ask them to use their talents to build separately,
| you'd end up with a lot more innovation and productivity, I'm
| pretty certain of that._
|
| You're misunderstanding how large companies operate.
|
| Their job is not to produce massive innovation -- that's what
| startups are mostly for, because most innovation actually fails
| in the market. Once innovation is proven, a big company like
| Google or Facebook can buy it to scale it larger and with less
| risk than the startup could have on their own.
|
| Google's job has been to increase revenue, and they've been
| doing a great job at that. The productivity increase happens
| from building enterprise features, hiring gigantic sales teams,
| etc. Building Google Cloud.
|
| And separate chat apps is necessary when WhatsApp and Slack and
| iMessage are eating your lunch. You can't risk having a single
| chat app that fails -- so you build one (Duo) that competes
| with WhatsApp and iMessage, another (Hangouts Chat) that
| competes with Slack, without pulling the plug (yet) on the
| legacy Hangouts.
|
| So if you took all 80k people, as you suggest, you'd wind up
| with a mess of startups which will mostly fail. You're not
| going to wind up with Google's actual increases in revenues,
| that's for sure.
| gustavo-fring wrote:
| I understand that's how lots of big companies operate, but I
| disagree that's how companies have to or should operate. The
| 80k thing isn't he notion that you'd get 80k success stories
| (you won't), but rather that if you had a .01% success rate,
| you'd still end up with 8 successful companies out of that,
| and the market is big enough for those 8 companies doing
| different things, making lots of money, and creating
| jobs/value. But more importantly, I feel like it would be
| better for us as societies.
| eloff wrote:
| I was recently reminded of this while reading posts on hn
| wondering why Lyft and Uber have thousands of engineers and what
| do they do all day.
|
| I wonder if this was reposted here for the same reason.
| crnkofe wrote:
| I've heard plenty of comments like that. People often trivialize
| things they don't understand. As a developer I tend to focus on
| that one feature I know how to build and ignore the rest.
|
| Or in other words - it's easy to bake a bread loaf but running a
| bakery is much more complicated.
| yingw787 wrote:
| God. I remember reading this a year ago.
|
| I've been working on TinyDev for about...two months longer than I
| thought I would have, and I still have probably a month left to
| go before it's completely ready. Just the amount of ops work you
| need to do in order to lock down your stack is absolutely insane.
| That's assuming you invest in ops work in the first place, which
| many places don't, hence technical debt and war rooms and fires
| and the slowness of project management resulting in massive
| backlogs and the like.
|
| I'm going to do a writeup hopefully up this weekend on backend
| level to VPC level work, just so that I can lock in my learnings.
| What I can say now is, the only easy day was yesterday.
| code4tee wrote:
| I like the post but it does somewhat miss the point of these
| comments when they're made. It's not usually someone saying they
| could rebuild the whole site / product / company in a weekend but
| rather challenging the value that everything beyond MVP is adding
| and all the staff that go into supporting everything beyond MVP.
|
| Companies tend to vastly over-complicate things and to support
| that end up having ever growing teams to support the ever growing
| over-complexity and feature bloat.
|
| I can't tell you the number of times a team has said it takes so
| long to deliver something with 3x the number of engineers because
| they need more testing, backend and such but meanwhile the core
| product features that customers care about are delayed and not
| materializing. It's not that these other things don't matter but
| all the "other stuff" shouldn't take priority over having a lean
| and mean product that works and people use.
|
| Thus it's less "why does this company have 100 engineers" and
| more "why does this company not just exist as a far simpler and
| leaner product?"
| cmckn wrote:
| > It's not that these other things don't matter but all the
| "other stuff" shouldn't take priority...
|
| Totally agree with you; I think the sentiment behind "I could
| do that in a weekend" is that shipping the core functionality
| can be done quickly, and iterating on the "other things" can be
| done after launch in many cases. Not everything has to be as
| robust as possible on day one. Google didn't have BigTable,
| MapReduce, and Borg the day the search bar went live. Shipping
| features is my favorite part of the job, it'd be great to have
| those wins as often as possible and cross other bridges when we
| come to them.
| paxys wrote:
| Simply because there is demand for that "other stuff" that you
| are writing off. Every user and organization has their own
| workflows and are looking for different things when they spend
| money on a piece of software. What you consider a core feature
| others may not use at all.
| code4tee wrote:
| What you describe is often part of the problem. Companies are
| often far to quick to chase after every feature request and
| endlessly customize product for each customer.
|
| Finding the balance between meeting true feature needs and
| ending up with a mess designed by committee is the ultimate
| art in product development.
| twhb wrote:
| To make this website readable in Chrome, load the page, type
| "javascript:" into the URL bar (it can't be copy-pasted there),
| paste the following paragraph after that text, hit enter.
|
| document.body.style.cssText = 'max-width: 35em; margin: 0 auto;
| padding: 1.5em; line-height: 1.4;'; 0;
|
| In Safari, Firefox, and Edge, I recommend just using reader mode.
| kstrauser wrote:
| I wholeheartedly agree, to a point. Sometimes hideously complex
| things look so easy because really smart people came up with a
| particularly elegant solution, so any rando off the street sees
| it and figures they could reproduce the thing.
|
| However, I worked for a company who had a whole team of engineers
| and QA people working for months on what was basically a Django
| CMS, but with a large dose of "not invented here"-driven writing
| of everything from scratch. I'd finally gotten tired of it, so I
| spent a weekend at home implementing it in Django and being done
| with it.
|
| I did learn two very important lessons, though:
|
| - The other stakeholders _really_ did not like someone
| demonstrating a working prototype of something they 'd been doing
| unsuccessfully for months, and I got a thorough chewing out for
| disrupting their processes.
|
| - I really didn't want to work for such an organization, and was
| much happier after moving to a smaller, more nimble company.
| potta_coffee wrote:
| I came to a new company and built a working prototype of
| something in a few weeks that apparently, a whole team had
| failed to do in more than six months of struggling. I didn't
| know that the project had already been attempted. Some people
| really didn't like me after that.
| [deleted]
| munchbunny wrote:
| From my experience, when I'm working on real world problems of
| nontrivial sizes and I see a big chunk of well organized, like
| a really well organized service, almost always it's because
| that was the latest cleanup/refactoring effort that happened
| after many years when the problem space was a moving target,
| and finally it stopped changing long enough to come up with a
| clean abstraction.
|
| The cleanest code I've ever written has always been on the
| second or third try. Write it once, test it against the real
| world, then rewrite it to take the new discoveries into
| account. It's too bad we rarely have the luxury of breathing
| room to rewrite things.
| kstrauser wrote:
| I wholeheartedly agree. This was a brand new project, though.
| Aeolun wrote:
| > The other stakeholders really did not like someone
| demonstrating a working prototype of something they'd been
| doing unsuccessfully for months, and I got a thorough chewing
| out for disrupting their processes.
|
| They aren't there to solve problems. They're there to receive
| their paycheck :/
| pandesal wrote:
| Great read. HN and reddit comments like the post title always
| irks me whenever a product is talked about in here or in reddit.
| duxup wrote:
| I think the HN comments about "what do they all do" are more
| often than not inquisitive ... or not entirely off the ball as
| far as "This product could be great if the company running it
| wasn't trying to be a unicorn and thus spending all that money
| with little more to show for it."
|
| I don't think those are unfair questions / concepts.
| MattGaiser wrote:
| I would find it hilarious to throw a QA team at one of those
| weekend builds.
| starpilot wrote:
| Hey, now. I built a PHP CMS for my friend's university club
| website 12 years ago in a weekend. It had user accounts,
| profiles, user posts. That's pretty much proto-Facebook,
| right? I could just scale that up to a billion users, right?
| /s
| CarVac wrote:
| I never have this problem because it always takes me solid weeks
| to properly design and implement a single new feature in my photo
| editor's user interface. Sure, I could slap something shitty
| together in a weekend, but then you have a shitty UI and people
| complain about open-source software UI enough already.
| Silhouette wrote:
| Someone with considerable but realistic skill _could_ build a
| passable approximation of a lot of successful web apps in a
| weekend, and a very small team of good people could probably
| build a production-ready version in a month.
|
| It's the other 95% of what the original business did to become
| successful that usually gets overlooked.
| forrestthewoods wrote:
| https://en.wikipedia.org/wiki/Coastline_paradox
|
| The devil is always in the details.
| grandridge wrote:
| Except when Uber and Lyft were kicked out of Austin, ride austin
| was up in a matter of weeks
| steveklabnik wrote:
| Ride Austin is wonderful, but does not do the same thing that
| Uber and Lyft do. Namely: they're only in Austin.
|
| Additionally, from their own site:
| http://www.rideaustin.com/faq
|
| > How much has it cost to build RideAustin?
|
| > The tech community contributed technology to power the app
| that costs millions to develop - but it also took over $7
| million in cash donations and significant in-kind services
| donations to make RideAustin what it is today.
|
| That is non-trivial.
| varjag wrote:
| When a taxi company here contracted to build their own hailing
| app, it was done to the tune of EUR500-600K. Every bit as good
| as the big rideshare apps.
___________________________________________________________________
(page generated 2020-04-29 23:00 UTC)