Ask HN: How many have learned a language they hated just to get a job?  - <AUTHOR> I'm an undergrad about to graduate here in December and I can't express how frustrated I am 'weeding through' all the .NET, C#, ColdFusion, J2EE, ASP jobs within 25 miles, not only on the obvious job boards, but on my School's Engineering job board as well.<p>I could very well be looking in all the wrong places (openings within my commute), but if I can't find an opportunity I can properly invest my talents with while working along side other developers/designers than going to sink my time learning a language I'll probably end up hating. <comment><USER2> Learning a language you hate takes you very close to hating the entire job, which is no way to work. Never settle for that, life is too short.

Keep working on side projects that _do_ interest you, and make them public, so that it's always easy to show prospective employers what you can really do. Spend your time boosting your skills and having fun, even if your first actual income comes from something completely different, like mowing lawns.

One thing about programming is that it can be done from anywhere; try applying for a job that's outside your local area, and see if there are any that allow remote work. Some companies won't offer this unless you have years of experience, but some might do it anyway; it all depends on how good they think you are.

</comment><comment><USER3> I just wanted to tell you that what you've learn in other languages are usually usable in many languages, even if it's not standard procedure. For instance, with C++, you can use Boost and use foreach with a (kind-of) lambda. It's not a real closure, but still, my point is that don't dismiss things of your favorite language when you need to use other ones.

I remember implementing a genetic algorithm in C++.. I used a functional way of doing it and it turned out to be a real pleasure. I even made it multi- threaded using a STL-like threading library which encouraged a functionnal style.

And also, don't forget, by learning new language, it will make you a better programmer, period. There are also way more than "programming" in a software job.

Communication between developpers, Communication with the client, designing a robust system, etc. Implementing in your not-so-favorite language might only be a small pourcent of the real job.

That was my 5 cents on the subject :p

<comment><USER4> Okay, this comment will sound trollish, but that's not my intent. I am not an C++ advocate by any stretch of imagination and I presently program in Java for living (and certainly like my job). Note, however, I am also speaking of in the context of professional programming, not open source projects/communities.

I tend to find that C++ jobs and the C++ developer community is usually (key word being usually, not always or even "almost always") more pleasant than the Java and even dynamic language jobs and communities.

I'd guess first reason is that C++ isn't very useful when you're doing simple work (such as data base driven websites, although it's certainly possible e.g., okcupid). The sort of projects where _only_ C or C++ make sense tend to just be more interesting (embedded, systems programming, high performance/low latency computing).

As it isn't an easy language, it takes more motivation than just money to learn it when there are other choices on the market. It's difficult for all the wrong reasons: not because it introduces powerful concepts like Lisp and ML-family languages do (which take time and effort to learn and understand), but because of complexities of manual memory management (especially if your dev organization doesn't like boost::shared_ptr and boost::scoped_ptr), inadequate standard libraries (stl and boost are nice -- again, if your dev organization allows you to use them -- but you almost always have to go beyond them and build your own data structures), etc... However as a result of the difficulty barrier, people who program in it tend to be smart and passionate and are more likely to write tools in Python and Perl and learn Haskell in their free time.

Additionally, when the PHB mandates C++, he can appeal to the developers' favourite (and most dangerous) indulgence: premature optimization instead of telling the truth ("I don't want to get fired if I screw up, so I am going with Industry Best Practices"). I've seen organizations go Perl to C++ and OCaml+Scheme to C++. There would be discontent, but there usually wouldn't be an exodus. I've never seen companies go Perl to Java or C++ to Java without an exodus of developers (either _before_ the switch, allowing the switch to happen, or _after_ , caused by the switch).

</comment></comment><comment><USER5> Maybe a bit late, but here is my experience.

At the end of the job search I had to choose among two companies. One was developing in python, the other in php. At first I felt inclined towards the python-based one, mainly because of my taste in programming languages. I had sweared to myself I wouldn't do java, asp or php, and like you I was disappointed at the fact that the vast majority of job offers required those languages.

After getting to know both, however, I ended up going to the php-based company.

I realised that what I actually dislike of java & co., more than the languages themselves, is the mindset that the people pushing them _often_ have. Mind you, often, not always. And that was the key.

The people at my company started this project about 10 years ago, and at the time php was the natural choice. They're not the old-aged, process oriented, boring, enterprise-y. They're agile, quick, creative, curious. We use git, introduced and extremely cool release management strategy, started a new project in python, moved a lot of the functionality on the client (on the browser), and so far even the work on the php backend has been a lot of fun (~1 year into this job).

I'd say the key factor is: do they have a hacking mindset or a process- enterprise mindset? With the right people php can be fun too :-)

<comment><USER6> and of course: Do they play UT2004? And how much being made fun of would you have to endure for having to retype that obscure command in your ubuntu terminal just to get the Alt-modifier key to work again.

And don't get me started about averages...

Glad to have you with us :-)

<? if ('1foobar' == 1) echo " _sigh_ "; ?>

</comment></comment><comment><USER7> If you don't like the idea of uprooting yourself to find a job, you'd better move to a big tech area _now_. Don't put down roots in a place where your every career decision will be compromised by the lack of opportunities. Eventually some local downturn will force you to uproot yourself anyway, and all your career sacrifices will be for nothing. Just move to a huge tech hub right away, and then you can feel (relatively) comfortable putting down roots.

</comment><comment><USER8> On my CV I have "Languages used: C, sh, perl, awk, Maple, x86 assembly" immediately followed by "Languages NOT used: C++, Java, Erlang, Haskell, Python, Ruby, PHP, C#". I'm sure it has resulted in me not being offered some jobs, but I'm not sure if it has cost me any jobs _which I might have considered accepting_.

Don't ask what languages are being widely used. Ask first what jobs/companies you're interested in; then find out what languages they require.

<comment><USER9> Please don't take this question the wrong way, but what kind of programming jobs do you usually take?

<comment><USER8> My expertise is in computational algorithms, cryptography, and security; I sometimes wander into numerical analysis or data compression. I don't do _programming_ per se; but it's a tool at my disposal when a research or design problem requires it.

I'm not looking for a full-time job right now (I'm working on Tarsnap) but I do occasional consulting in the areas which interest me.

<comment><USER10> Do you actually _hate_ the languages listed under "Not Used", or do you just find them useless for the kind of work you do?

<comment><USER8> I dislike those languages, in part because I find them unnecessary for my purposes, and in part because I hate their fanatical adherents.

</comment></comment></comment></comment></comment><comment><USER11> Thesis- hating a language is a mark of a good but not great developer.

Hating the sort of work a language is usually used for is something different, however.

Perl is the one exception, of course. All right-thinking humans hate perl.

<comment><USER12> point : in your enterprisey java/.NET shop, you can play with clojure, scala, F#, groovy, j/iron Ruby/python, axum. Fun stuff. Write tests, build tools, analytics. if you get called on it, you can argue it takes less time to write support structure code in __, and you're a busy guy.

<comment><USER4> I'd love to see Perl6 released. By incorporating first order content free grammers, it could the same for CFGS that Perl did for regexes. That would be world changing.

As for PHP: structured, clean PHP (written by people with an education and development experience in other languages) looks like Java. So why not just use Java: you get better performance (without having to compile it to C++) and access to great libraries. Of course, now that you're on the JVM you might as well start using better languages (Scala, Clojure, JRuby), which to operations look like just another jar/war file.

</comment></comment></comment><comment><USER13> Think about moving after graduation.

If you hate your job it will seep into other aspects of your life. Life is too short for that.

Go out and find your adventure.

</comment><comment><USER14> I feel your pain. For my first "big corporate" programming job, I had to do PowerBuilder development. Coming from Java/C++ background, it was like hell on Earth.

I stuck around though, did PB for a while, and 2 months later a Java position opened up, which turned out to be great.

So - I wouldn't get too caught up in that, but YMMV

</comment><comment><USER4> I wouldn't worry about the language bits (as long as it isn't something entirely brain rotting like ColdFusion, ASP, PHP or COBOL), as much as by the fact they all seem like the usual enterprisey "read text from a database display it on a screen" jobs. A CRUD app in Ruby or Python is certainly a lot more fun to build than in Java (and most importantly, easier to maintain and modify), but it's still a CRUD app.

I'd suggest looking into a different geographic area, joining a _technology_ company (which produces a software product; serious Internet companies fall under that umbrella).

I'd recommend high-traction, well funded start-ups that have been around the block (with _serious_ technical identities); big tech companies like Amazon, Google, Microsoft or Yahoo are a good bet too: they solve very interesting problems and are willing to mentor you. Yes, they typically use various forms of blub for _production_ code. However, no one will object to you writing a prototype in Python (or an IDL->code translator in OCaml), and you'll be able to pick up skills that are rare and meet serious hackers.

The reason I don't recommend smaller start-ups is that their goals aren't always aligned with yours: your goal is to build up the skills needed to solve big, interesting problems; depending on the founders, investors and the market the goal of a start-up might be to make _any_ product, even if there isn't much technical skill (for you) to be gained by building that product.

Knowing something others don't know (it could be machine learning, search, compiler construction, systems programming, numerical analysis, etc...) means you're not a commodity. If you're not a commodity, you're much more likely to be allowed to use non-commodity tools (e.g., start a pilot project in Python, Erlang or Haskell instead of Java or C++, or start adding Scala modules to an existing Java application). It also means better pay in the long term, but you should _not_ use pay as a yard-stick when deciding on your first job: an MBA- type "founder" might be really desperate for you to a web app for him, but a software company is making an investment in you.

Edit: see the comment from cperciva -- if you have skills (in his case security and mathematics, from his FreeBSD and academic work) that others don't, you can find ways to use tools that you enjoy using: either by finding a workplace which uses these tools or having enough "clout" to introduce those tools to other companies.

</comment><comment><USER15> I very nearly learned C# just so I get could a job in my geographical area. Turns out, if I was a bit flexible there were a lot of jobs out there doing the PHP development that I really enjoy.

Don't make too many compromises though. Learning a language that you don't like is going a bit too far to get a job I think.

</comment><comment><USER16> You're looking on the wrong job boards most likely. I almost never see any of those languages where I end up seeing jobs.

Try looking at meetups (which allow job posts), job postings advertisements on programming sites, etc instead.

</comment><comment><USER17> I've learned a bunch of languages while working at justin.tv, and have disliked each of them to some degree. Think of it as the price of admission to being able to do interesting things.

</comment><comment><USER18> By not broadening your skill set and opening yourself up to opportunities using the languages you've listed, you are seriously limiting the scope of your job search anywhere. Don't let the "big buzz" on the web fool you, the majority of developers are holding jobs in shops that use Java, C, and C++.

That said, take the advice of people here and don't constrain yourself locally. You're at a perfect time in your life to be free and go wherever to find the work you really want. Take advantage of that freedom!

</comment><comment><USER19> my advice would be to simply apply to any job that you think you might be interested in, regardless of the language. most entry level positions have an expectation of a learning curve.

submit a cover letter that states how quick you are at learning new things and how you're willing to put time into learning their chosen language before you arrive.

for most companies, entry level hires are about picking up the talent, not the experience. demonstrate your talent and drive and you'll have a decent chance.

thats how i got my job, at least.

<comment><USER4> The only thing to avoid are companies that don't care about developer talent. Their goal isn't to grow talent, they want to find someone who will jump right in and meet their business needs (no more, but also no less) -- and when they leave, can be easily be replaced. That's why they're using these technologies: they can just look for somebody who knows Struts 1.4, Oracle and Spring (or w/e) (and these people are plentiful).

That's not to say they don't care about _any_ talent: it's just software development is neither their core competency nor a competitive advantage. They may have great pay and hours (and may be doing something great for the world), but if you're a programmer because you love programming, you should go (at least for your first job) to an employer that will invest in you.

<comment><USER19> best to avoid, perhaps, but even if you do throw them a resume, they won't interview you because you don't have the skill set. so, doesn't matter too much in the end.

</comment></comment></comment><comment><USER20> ColdFusion was the big one, I hate the language with a white hot passion now, no job is ever worth the abomination of learning that steaming pile of garbage.

To a lesser extent, C# I ended up learning only because a side project was in desperate need of more coders. I didn't like it much but nowhere near as bad as CF.

And lesser still, Java proper the language rather than the environment. I don't much like it but I totally forgive it because of the JVM and all the excellent other languages that run on top of it.

</comment><comment><USER21> I generally despise development. I can "program" (make small tools, scripts, etc) but I don't have the "developer mindset"

I learned PHP and MySQL to get a promotion when my boss was considering hiring from outside the company. I generally don't hate PHP -- in fact, these days, I rather like it -- but I did have to do something I was averse to in order to land a job.

</comment><comment><USER22> Programmers these days.

In my day we programmed in Java and liked it. ASP was the GOOD web programming language. We had to code up hill in both directions...

But seriously, there are good and bad points to every language. Sometimes I think the willingness to just love the good and work around the bad is half of being a really good developer.

</comment><comment><USER23> My first programming job was in VB 3.0. It was a horrible and awful experience at a churn and burn consultancy, but it was a job and gave me a chance to make connections, learn Perl, and get a better job that I liked much more.

If you don't have any experience you should accept that your first job is going to suck in some ways. I would suggest not worrying about the quality of the company or environment so much as the presence of opportunities to do different things, grow, and move on. Which you _will_ do at some point.

And in this market, being picky is particularly unadviseable. :-(

<comment><USER4> I'd actually suggest being picky about the first job. Reason for that is that once you're younger, companies are investing in you. Once you're older, they expect a return on that investment.

However, I'd suggest being picky not about the language used, but about the difficulty/challenge/"hard-core" feeling of the position. Pick the company that had the toughest interview questions (don't even consider one that doesn't ask you to write code on the whiteboard!), uses technology that is the most challenging (rather than simply complex), solves the most difficult problems and is willing to let you work on a team solving those problems (rather than assigning you to e.g., QA).

It's always harder to go "easy->tough" than "tough->easy". I'd hire a systems programmer to write web applications (if that's indeed what he wanted to do), but I'd be hard pressed to hire a web developer to do systems programming (unless he had open source work to show for it).

Additionally, right or wrong certain large companies prefer work this way: they hire new grads from the outside for junior positions and then hire internally (i.e., promote) for _core_ senior positions. They will, occasionally hire someone with experience from a comparable large company for a senior position (after a difficult interview), but they won't hire someone coming from a start-up for a senior and _core_ (i.e., software engineer vs. QA) position. The argument is that large companies have certain processes and challenges which are unique to them and don't occur in start-ups.

They also won't hire an experienced person for a junior position, knowing they (statistically speaking) won't be motivated enough while earning lower pay to advance through the ranks to fill a senior role.

So if you'd like to work in certain places (e.g., you want to be at IBM Research) it's _much easier_ to get your foot in the door as a new graduate.

I would say, there's may be a period of 2-4 years from "get your last degree" to "seen as damaged goods by big corp". In practice this means, you can try a particularly interesting start-up right out of college _or_ (if you feel your career is going nowhere), go back for a Masters and make yourself a "college hire" again.

It's not fair and there are exceptions (I'd imagine Google generally ignores various big-company anti-patterns in hiring, although they're still seen as "favouring new grads" by ignoring experience), but it's a possible consequence of choices one makes.

<comment><USER23> Interesting. Everything you say runs directly counter to my experience. However I've also never worked at the kind of large company that you're talking about.

With one exception. My first job involved consulting at Bristol-Myers Squibb. The result of that was that for some time I was unable to enjoy Dilbert cartoons because the wounds were too raw. They were true.

Based on that experience I wouldn't _want_ to work for that kind of large corporation. Luckily tech tends to be filled with young companies that grew up with very different cultures, so I've never again had to suffer through that kind of dysfunctional culture.

</comment></comment></comment><comment><USER24> I've never learned a language I've hated to get a job, but I've learned to hate many languages (or at least aspects thereof).

 _Learned_ being the operative word.

At this point in your career you'd be well served to learn idiomatic blub a few times over, in the same way you'll be well served to work with a variety of personality types.

When the time comes for your next venture, be it in 6 months, or 6 years, you'll make a better decision i.e. grounded in understanding, about each.

Rinse; repeat.

Edit:

I'm not suggesting you take just any old job, however. Be discerning.

</comment><comment><USER25> I learned "corporate" to get a job. It's comes with a huge collection of bizarre operators with baffling precedence rules and a template library that spews out errors to rival C++ STL circa 1999. It also changes, my most recent job introduced me to the "cloud" type which got everyone excited but then we learned it causes segfaults whenever it interacts with the standard "security" classes, and suddenly I'm managing two separate platforms.

</comment><comment><USER26> I've learnt Java (J2SE). I have an embedded systems background. Hated it at first (lack of possibilities vs C/C++), but in the long run there are benefits. Frustrations are still there and the fun is limited (no risk, no fun), but you can work your way out. Brainwashing yourself is option #1.

I still enjoy working on side projects too, with the tools I like (web dev, PHP MVC...).

</comment><comment><USER27> I would suggest that the correct thing to do at that point is to move somewhere with a better tech community in the languages you do like.

I moved(without having and commercial experience behind me) to a more technical city just as I was finishing Uni and managed to find a much better job with much better coworkers than I could have had in my starting city quite quickly.

</comment><comment><USER28> I never "hated" Perl, but I only learned how to use it because I heard it was pretty useful. It grew on me and I now love it.

<comment><USER29> Perl was my first language, and my progress suffered as a result. Don't get me wrong, I love Perl and use it for things, and while there are many ways to do things, most of the ways are fairly awful, and I had to go through many iterations of writing the same code to now at least be somewhat confident. Probably as a first language it would've been nice to be forced to be clean initially! Perl allowed me to get away with so much..

</comment></comment><comment><USER30> So you don't want to work with .NET or Java or ColdFusion or ASP (classic ASP 3.0?). What do you want to work with?

</comment><comment><USER31> How can you hate any language until you have spent the time to learn and understand it?

<comment><USER4> > How can you hate any language until you have spent the time to learn and > understand it?

There's also a risk that if you don't know a popular, but bad languages (or at least take time to understand why people call it bad, rather than just read what other people have said), you won't know to avoid other languages built along the same lines.

Also, while a language _overall_ might be unpleasant, it can still teach you new concepts. I had to be dragged screaming and kicking away from Perl and C++ into Java. However, Java has got me thinking "if only there was a garbage collected statically typed language with a good concurrency/threading story that wasn't as verbose, had first class functions and (optionally) did some form of MI/mixins". That thought lead me onto Scala, OCaml and (once I have some free cycles) Haskell.

</comment></comment><comment><USER32> Get a job somewhere with cooler jobs? Like the SF Bay? Seems like the obvious fix.

<comment><USER4> Or Seattle, WA or Boston, MA. Additionally Austin, TX and Portland, OR.

Honestly, Bay Area (and especially San Francisco proper, rather than Silicon Valley) do suffer from too many "widget" start-ups, which should be viewed as media companies, solving social problems -- _not_ technology companies. New York and LA start-ups tend to be even worse in that respect.

When I visited Boston, I noticed the start-up scene had a more of a "hard-core tech" feel to it. I saw purely technology start-ups. The people calling themselves entrepreneurs were _engineers_, not marketers and project/product managers (as is often the case in Bay Area; note: that's not to say PMs and markets aren't important!). There was more "ZFS vs. btrfs" talk and less "agile lean customer development start-up" talk.

<comment><USER32> There's plenty of real tech in the SF Bay -- you just have to have enough sense to look for it since, yes, the signal-to-noise ratio in SF is a lot worse than other tech areas.

<comment><USER4> Not implying there isn't. Quantitatively, there is likely still more real tech in Bay Area than anywhere else. I am in Bay Area and likely not going anywhere :-) It's the signal-to-noise ratio can be distracting and upsetting for somebody new. I've seen lots of smart young technologists waste away implementing a "business guy's" vision and (after three-four years of nothing but web development) end up unhappy, but with few other career options.

</comment></comment></comment></comment><comment><USER33> JavaScript is my hated-needed

</comment><comment><USER34> Where do you live?</comment>


Ask HN: Learn Ruby by Reading Source Code - <AUTHOR>

Hello HN,
I'm learning Ruby and I was looking for some excellent open source code to read.
I'm already writing some code (following tutorials, etc.) but I would love to see some real world examples. I would like it to be simple enough for a beginner to follow along, while demonstrating the best practices for the language.
Thanks for your time and if you have any other suggestions to improve my skills with Ruby, I'm definitely open to hearing them. <comment><USER2> <https://github.com/sinatra/sinatra>

<https://github.com/stefankroes/ancestry>

<https://github.com/jnicklas/carrierwave>

<https://github.com/ernie/meta_where>

<https://github.com/ryanb/cancan></comment>


Ask HN: What is something you would recommend learning in a day? - <AUTHOR>

I want to pick up a new skill in a day or two. Whether it be a new programming language, API, or something completely unrelated to technology, I'm open to ideas. What do you suggest? <comment><USER2> Origami! It's always fun and there are a ton of resources/guides/tutorials online. Most projects are usually short and practically all are doable in a day. Plus, many projects are cool to show off. Some are even useful! Here's a favorite of mine (simple, takes a couple minutes):

<http://www.ehow.com/how_4563591_origami-bookmark.html>

However, don't go overboard with the paper :-)

</comment><comment><USER3> Try ballroom dance. You may be able to find a social dance or a group lesson. It's a good skill to have, and usually good fun, too.

<comment><USER4> I would argue that this takes more than a day or two.

<comment><USER3> Given, but he could at least learn a few basic steps, enough to get around the room. He'll also get the exposure to something new, which is most important (and probably what he's looking for).

</comment></comment></comment><comment><USER5> Learn to surf. Or snowboard. You won't master either, of course. But standings up on your first wave or learning to link turns on the snow is exhilarating, and the first step towards getting better.

</comment><comment><USER6> I spent some time the last couple days learning two songs on a penny whistle. Great fun.

</comment><comment><AUTHOR> I thought this would have had more discussion going on, what with everyone here constantly picking up new topics. Anyone else?

</comment><comment><USER7> How to cook something: how to make an omelette or how to bake bread.

Or how to fix something: a leaky faucet or toilet.

</comment><comment><USER8> Juggle, or ride a unicycle.

I also second the recommendation to ballroom dance.

</comment><comment><USER9> jQuery</comment>


What is Android doing when it says "optimizing apps" after a system upgrade? - <AUTHOR> http://alvinalexander.com/android/what-android-doing-optimizing-apps-after-system-upgrade-restart <comment><USER2> Compiling & optimizing the bytecode

</comment><comment><USER3> Removing apps it doesn't like, like Windows 10?</comment>


The Architecture of Git (2012) - <AUTHOR> http://aosabook.org/en/git.html <comment><USER2> The best (known to me) informal intro into the architecture of Git is The Git Parable: [http://tom.preston-werner.com/2009/05/19/the-git- parable.htm...](http://tom.preston-werner.com/2009/05/19/the-git-parable.html)

<comment><USER3> Also greatly worth reading: "Git from the Bottom Up":

* HTML version: [https://jwiegley.github.io/git-from-the-bottom-up/](https://jwiegley.github.io/git-from-the-bottom-up/)

* PDF version: [http://ftp.newartisans.com/pub/git.from.bottom.up.pdf](http://ftp.newartisans.com/pub/git.from.bottom.up.pdf) (via [http://newartisans.com/2008/04/git-from-the-bottom-up/](http://newartisans.com/2008/04/git-from-the-bottom-up/))

The great thing is that after reading and understanding these, one's mental model matches the reality of the Git program, so one can both try bolder things, and get unstuck from any mess.

<comment><USER4> I recommend this constantly, it is excellent.

Not to outright beginners, but anyone past that point should read this. It is a great job of clearly presenting an accurate mental model that helps you use git. If you are already a git expert this is just a good thing to learn from in general and with how to explain and teach git usage in particular.

The only documentation I know of that can turn people from cargo cult git users to people who just do the version control things they need done with the parts of git they need. That is damn useful.

</comment></comment></comment><comment><USER5> I had come across this gem about understanding the vi editing model a while ago:

"Your problem with Vim is that you don't grok vi."

It's the top answer on this StackOverflow question:

What is your most productive shortcut with Vim?

[https://stackoverflow.com/questions/1218390/what-is-your- mos...](https://stackoverflow.com/questions/1218390/what-is-your-most- productive-shortcut-with-vim)

Wonder if there is any such post about Git that cuts to the chase, even for a part [1] of the Git model, and explains it clearly [2].

[1] I had also come across a StackOverflow post that explains a part of git very clearly, like the vi example I quoted. I think it was about how to roll back accidental changes using "git reset --hard" and variants. Saved it, but don't have it handy right now.

[2] Note: I said "clearly", not necessarily "simply". I like to quote the (probably out-of-print) book by Abbe Dimnet [3] called The Art of Thinking, in which he said something like this (while deploring the trend of books that try to make things artificially simple, a.k.a. dumbed down):

"French grammar cannot made simple. It can be made clear."

[3] [https://en.wikipedia.org/wiki/Ernest_Dimnet](https://en.wikipedia.org/wiki/Ernest_Dimnet)

He also wrote a book on that same topic (French grammar made clear). Googled the former book recently and saw about the second book. I've read the first, long ago, which I found in a second-hand bookshop. Good book. Apparently it was a best-seller at the time it came out, according to Wikipedia.

Quotes by him:

[https://en.wikiquote.org/wiki/Ernest_Dimnet](https://en.wikiquote.org/wiki/Ernest_Dimnet)

</comment><comment><USER6> I'm surprised that it's not mentioned in the article that one of the most interesting architectural aspects of git is that it's a blockchain system.

<comment><USER7> That's arguably _not_ the most interesting architectural aspect of Git.

Or does any back-linked tree data-structure becomes interesting if the nodes keep a hash of their parent instead of a raw reference? I don't think that's the case.

It might be a bit heretical but I don't think Git has a super interesting internal architecture. I'm not downplaying the fact that Git was very innovative, especially considered the landscape of SVMs at the time. The tool as a whole is great and has desirable properties but its internals don't strike me as particularly innovative. It's a clever composition of solutions to well established problem domains. And in that aspect it is a beautiful engineering solution although there is room for a lot of improvement in terms of UX.

And in addition to that, I would argue that it would be a very weak definition of "blockchain". The innovation in Bitcoin is the incorporation of proof-of- work and resulting alignment of incentives such that it can achieve probabilistic consensus in an adverse setting and with some degree of asynchronicity.

The underlying structure of the data is an obvious choice because it is simple and "captures" the idea of aggregate global state, but it's also hardly an important innovation. UTXOs are more significant.

And also, recall that the textbook example for state-machine replication is always an append-only log for example. So that's not the crux of it, or of blockchain, in my humble opinion.

<comment><USER6> I said one of the most. I didn't declare it the most...

</comment></comment></comment><comment><USER8> Very informative. This explains well about why Linus once said signing every single Git commit is unnecessary and it only means you have automated the signing process. [1]

[1]: [https://news.ycombinator.com/item?id=12290873](https://news.ycombinator.com/item?id=12290873)

</comment><comment><USER9> Not sure if it's of any relevance but I recently discovered [https://gitup.co](https://gitup.co) and must say, it's pretty cool.

<comment><USER10> Frickin' _amazing_ UI design, and some great pieces of functionality (edit the commit graph directly; ability to undo most operations).

Unfortunately development seems mostly paused, and it still has some big gaps...

Still tho by far my favorite git client. (#2 would be Sublime Merge.)

</comment></comment><comment><USER11> I still recommend people to watch this video from the man himself, Linus Torvalds, if they really want to understand the architecture and data structure behind git - [https://www.youtube.com/watch?v=4XpnKHJAok8](https://www.youtube.com/watch?v=4XpnKHJAok8)

If I remember correctly, he mentioned that he wrote the MVP in 4 weeks and the data structures he used are quite simple. Never got a chance to look at the source code but I guess they are in github (at least the mirror copy.)

<comment><USER12> It only took 4 weeks plus 30 years of programming experience and a genius mind.

</comment></comment><comment><USER13> The whole website is a treasure trove for learning about system design.

</comment><comment><USER14> "The Architecture of Open Source Applications" is great. I highly recommend their other articles, as they are all interesting and informative. If you can, throw a few bucks their way by buying the PDF or paperback versions.

</comment><comment><USER15> I still prefer my book's history of Git in which I compare Linus rejection of Monotone to the movie "Back to the Future":

[https://github.com/xrd/BuildingToolsWithGithubBook/blob/ca7f...](https://github.com/xrd/BuildingToolsWithGithubBook/blob/ca7f2c0b24496019a56fb1a1e3d81c752d601082/old/chapter- bootstrapping-git.asciidoc#monotone)

<comment><USER16> Interesting, what am I reading?

<comment><USER15> This (a book about building tools with Git and the GitHub API) was published by O'Reilly in 2016, and we just released it under creative commons. You can read it completely free at [https://buildingtoolswithgithub.teddyhyde.io](https://buildingtoolswithgithub.teddyhyde.io) or get the repo of the book contents above.

</comment></comment></comment><comment><USER17> I've found this online course by Paolo Perrotta to be the best introduction to Git's architecture, by far: [https://www.pluralsight.com/courses/how-git- works](https://www.pluralsight.com/courses/how-git-works)

He takes you pretty much from first principles all the way up to how remote repositories are tracked. Its been far more useful to me than simply trying to learn the CLI.

I realize its behind a paywall, but I'd recommend signing up for the free trial just to watch this course (if you're curious about the inner workings of Git).

</comment><comment><USER18> Git is the VCS most suitable for bottom-up learners. Which is the VCS most suitable for top-down learners?

<comment><USER19>
        > Which is the VCS most suitable for ....

Git.

It doesn't matter what your question is. :-)

I mean, come on, it's not like you have a choice. You gotta use whatever your teammates/coworkers/organization is using.

That said, yeah, there's a lot of pedagogic problems with git stemming from the INSANE inconsistency of command-line. The only redeeming quality? It works and it's popular.

<comment><USER20> I really hope Git isn't the end of the road for VCS. I work in visual effects and video games. Most video game studios still begrudgingly use Perforce for project data. Many also have a separate Git server for code. Perforce or SVN is still the go to solution for binary assets. Trying to explain Git to programmers is difficult enough, for artists who have never used the command line it is unreasonable. Every time I've seen an "asset library" it's usually written from scratch instead of built on another VCS. I've made some crude attempts at building on Git and the data just structure isn't appropriate.

I know it's a bit unreasonable to expect the same tool for everything (but that's what you were implying). The binary problem is more manageable for code with a few UI assets (like icons), but isn't great.

<comment><USER21> I work in web development and Git has usually been good enough for our projects. But recently we have had a few projects that used large files and started using git-lfs in those. Is git-lfs not good enough for storing large assets in a git repository?

Speaking of non-coders using a VCS, our designers use Sketch (a macOS app) and until recently have used Dropbox for sharing and put the date into the file name as a form of version control. But they have now started using the Abstract app ([https://www.goabstract.com/](https://www.goabstract.com/)) which is a fancy UI around git (I think, not sure though), but none of that VCS complexity is leaking through. And they seem to like it. So maybe all it takes is a custom GUI that's tailored for a narrow and specific use case.

<comment><USER20> On those web projects, is Git used just for versioning the delivered assets (psd, jpg, and gifs) or is it used for the working files (Illustrator, Photoshop, etc)? I've used it for the former, which is why I said it was more manageable, but not a great solution. If you were to treat it like we do code, you'd only commit the working files and have a build script to generate the deliverables.

Those are tooling problems, but I also think there are architectural problems. I don't have a lot of experience, but I have looked at git-lfs. You need a separate repo and also a separate path for data, right? It's also an add-on. It's all working around Git itself. For artists, what's the value add over Perforce or SVN? I can see that maybe you could use the same tools as the coders, but you have a bunch of new problems. I'm not saying it doens't have its place. I can see myself using it in the future, it just doesn't look like an out of the box solution.

A few years ago I was toying with something that would be more like how a lot of backup systems work (and I think macOS attempted something like this a few years ago and abandoned it). Each time you save it will make an auto-commit, if your app has integration, it takes a screen shot and stores any metadata from the scene (this was targeting a 3d application, but with the goal of also working with the filesystem directly). You could also make an explicit commit and give a commit message. Auto-commits would get flattened into hourly, daily, weekly. Explicit commits would stay around as indefinitely as you'd want. Git was a poor backend for this because I don't think you can merge commits in the background, that also rewrites history. This was focusing on version control for an individual, ignoring collaboration and merging.

The whole reason Git was written is because the data-structures facilitate the needs of the Linux kernel's programmers more cleanly ("Bad programmers worry about the code. Good programmers worry about data structures and their relationships.") I feel like a lot of these Git tools for artists are coercing Git's data structures into an awkward workflow. That's the biggest reason why I hope it's no the end of the road for VCS.

Thanks for introducing me to Abstract. I know I've seen similar attempts in the past. I hope it's useful to artists and I hope Abstract is a successful business, but I'm a bit bummed that Open Source is relegated to a sub-group of programming.

</comment></comment></comment></comment></comment><comment><USER22> I loved the AOSA books, but there's been sometime that they don't publish a new one.

Do anybody know if there is something new in the works?

And of any other similar books?

<comment><USER23> Have you already read all of them? I was calculating how long it would take me to read and understand every chapter of every book. I usually like to write small snippets of code or look for references and stuff for books like these.

Anyway, if I read, say, one chapter every Monday, it would take me about two years to complete the books!

Probably not a problem that there's "nothing new" since the books seem to be more about timeless design principles and less about novelty.

</comment></comment><comment><USER24> The fourth paragraph in section 6.2 refers to "BitMover" with no previous context. Copy-paste error?

<comment><USER25> there is context in the intro (see bitkeeper)

<comment><USER24> I found nothing about BitMover here:

[http://aosabook.org/en/intro2.html](http://aosabook.org/en/intro2.html)

<comment><USER25> sorry, I meant in the git background section 6.2, it briefly mentions BitMover as the developer of BitKeeper, but that's all needed to know about it

</comment></comment></comment></comment><comment><USER26> > To understand Git's design philosophy better it is helpful to understand the > circumstances in which the Git project was started in the Linux Kernel > Community.

I don't understand this sentiment. It's not helpful to know the history at all. At best, it romanticize the choices made. Stating the goals would be an intro that shows some level of analysis.

<comment><USER27> No, the author is right. Git us in its core a database for managing patches. Understanding the needs of Linus Torvalds as his role of Kernel maintainer is about the only good way to understand why git is so strangely designed.

<comment><USER28> Darcs is a database for managing patches. Nothing in Git inherently cares about patches. To a first approximation it's a database for managing full snapshots of trees of files.

<comment><USER27> Git only needs lists of files because it needs entry points into its lists of patch fragments that make up the file and to assign file names to them. Other than that, a changeset is just another name for a patch that can be added, altered, rewritten or removed. That makes git a patch database in my book.

Darcs feels more like a research project to me. The developers try to find a theoretical foundation in which they can base a VCS, but they have not managed to make their theory work with the level of perfection that they want. But if they eventually get it right, it will probably have the provably best text- based merge tool possible.

<comment><USER28> This is not how Git's data model works. You may be thinking of delta- compression which during "git gc" and _purely_ as an optimization step does delta-compression across content in the repository.

But that's purely an optimization that has nothing to do with the intrinsic data model. There's no point at which the patch output you see with "git diff/show" is actually stored as-is in Git. It's computed on-the-fly.

This separates Git from many other SCMs where patches or other deltas are permanently stored at the time of commit in a way that can't modified afterwards.

The distinction matters because those systems generally have storage that doesn't compress as well, since they need to compute and store a diff at the time, whereas a system like Git can keep finding better delta candidates as history progresses.

This goes all the way back to the likes of RCS. The Subversion FSFS backend also works like this, and I believe Mercurial to some extent, and certainly Darcs since storing a history of patches is what it's for.</comment></comment></comment></comment></comment>


Faster than a speeding rabbit: speed, sync, and settings - <AUTHOR> http://chrome.blogspot.com/2011/02/faster-than-speeding-rabbit-speed-sync.html

<comment><USER2> Really enjoy the page like UI instead of a popout window. If you're in Chrome: chrome://settings/browser

</comment><comment><USER3> Glad to see that the new beta now allows you to set a master password for sync as well.</comment>


Soyuz 2-1b launches latest GLONASS-M satellite – despite being hit by lightning - <AUTHOR> https://www.nasaspaceflight.com/2019/05/soyuz-2-1b-glonass-m-satellite-758/ <comment><AUTHOR> If you're not reading the article - it's long and not that interesting if you're not into it - then just go and check out the picture. The interesting part is the lightning strike seemingly skipping a distance. The exhaust is very conductive (the gases are ionized/a plasma due to temperature) and thereby serves as a sort of shortcut between two points in the atmosphere (and the metallic rocket body does that of course as well). The skipped part is where no combustion is taking place anymore but there are still enough ions to conduct. Below that, the lightning strike propagates as usual. It's not clearly visible but the lightning strike will be most likely following the exhaust trail.</comment>


Lifelong Rubyist makes some Python code 5x Faster - <AUTHOR> https://www.schneems.com/2017/10/02/lifelong-rubyist-makes-some-python-code-5x-faster/ <comment><AUTHOR> Neat post but would have loved to have seen a side-by-side comparing the suboptimal code with the optimal code.</comment>


Ask HN: What's harder to understand, JavaScript's "this" or Frisbee physics? - <AUTHOR> <comment><USER2> Most math books/papers come complete with definitions(incredibly helpful), theorems and proofs. In other words they are "well-documented" in programmer talk. Books on programming language semantics/syntax and general physics haven't reached the level of anal-ness that math texts exhibit when it comes to details, definitions and consequences. So, I'd say whichever comes with more hand-wavy (non)arguments is more difficult to pick up unless you're up for straight up memorization.

</comment><comment><USER3> There's only 5 possible cases that determine the value of the "this" keyword, so I'd say that frisbee physics are harder.</comment>


Company to Freeze Your Body Before Death: Pay in Blockchain Based Cryptocurrency - <AUTHOR> http://longevityfacts.com/cryonics-cryogen-cryopreservation-freeze-body-death-pay-new-blockchain-based-cryptocurrency/ <comment><USER2> Control over your own end of life decisions is a right that is routinely denied in most of the world. It is a sad state of affairs. Similarly for medicine, and the right to choose your own medication and medical procedures.

Cryopreservation is a time-sensitive operation, and in practice akin to a surgical operation in the tools and people required. It runs best with preparation and forewarning, and as soon as possible after death. The primary cause of poor preservation and increased cost is the delay and rush forced on people because planned euthanasia is illegal in most jurisdictions, and as a result the providers are forced into a standby/emergency response model of operations.

Cryopreservation should be a form of euthanasia for best effect, for the lowest level of cell and tissue damage, and for the best odds of future restoration.

</comment><comment><USER3> Yes, Reason. In fact the article doesn't contradict what you said. And that's what the comapny is trying to do. Albeit with an overly ambitious plan.</comment>


Time Series Prediction – A short introduction for pragmatists - <AUTHOR> https://www.liip.ch/en/blog/time-series-prediction-a-short-comparison-of-best-practices <comment><USER2> And now for the great thing ... Prophet uses Stan underneath [1] and thus is built on foundations of 'regular' Bayesian statistics. Andrew Gelman has written about Prophet as well [2].

After reading this blog I am tempted to get the ML for time series book though. I'd love to try and compare some less than trivial examples with covariates involved.

[1] [https://peerj.com/preprints/3190/](https://peerj.com/preprints/3190/)

[2] [https://statmodeling.stat.columbia.edu/2017/03/01/facebooks-...](https://statmodeling.stat.columbia.edu/2017/03/01/facebooks- prophet-uses-stan/)

<comment><USER3> Facebook prophet is really impressive and has gotten us better precision with shorter iterations even with large datasets compared to CNN+lstm.

We run it over millions of inventory over years of data and it has given satisfactory results in majority of the cases

<comment><USER4> have you tried xgboost? in our problems none of the LSTM/Fbrpohpet/arima performed better fine-tuned xgboost model.

<comment><USER3> Just looked it up. Looks super interesting, I will surely give it a shot. Thanks

</comment></comment></comment></comment><comment> chroem- Basis function regression is a very under-appreciated method for producing time series forecasts. I've found that it beats most of the methods described in this article. Maybe I should make a blog post...

<comment><USER5> Sorry for ignorance. Did you mean to say Simple Linear regression or something else? Do you have any reference for that?

<comment> chroem- Yes, it's an extension of linear regression. You can incorporate different basis functions to model trend, seasonality, the effects of external regressors, different frequency components, etc. It gives you a lot more control over the forecast model.

<comment><USER6> Are you referring to Generalized Additive Models (GAM)?

<comment> semi-extrinsic I think GAMs are more for the case where you have many underlying input variables and a single resulting response.

<comment><USER7> This is a less studied senario for time series research: contextual forecasting. With enough contextual information, forecasting doesn't need to squeeze the information from its own history that hard.

</comment></comment></comment></comment></comment></comment><comment><USER8> Here are some old references for the problem of the OP:

David R. Brillinger, _Time Series Analysis: Data Analysis and Theory, Expanded Edition_ , ISBN 0-8162-1150-7, Holden-Day, San Francisco, 1981.

George E. P. Box and Gwilym M. Jenkins, _Time Series Analysis --- Forecasting and Control: Revised Edition_ , ISBN 0-8162-1104-3, Holden-Day, San Francisco, 1976.

Brillinger was a John Tukey student at Princeton and long at Berkeley.

</comment><comment><USER9> Normally the method for dealing with 'time series' is really just finding ways to turn a non-stationary distribution into a stationary distribution, where you can then apply classic statistical methods on them. So you're just finding ways to factor out the time component in the data so you can use the standard non-time sensitive regression models on the transformed data.

I don't think it's untill you get to the NN based models that they start treating time as a first-class component in the model.

* If I'm wrong please explain why instead of downvoting

<comment><USER10> A (weak) stationary distribution has no trend, no seasonality, and no changes in variance. With these properties, predictions are independent of the absolute point in time. The transformations to turn non-stationary series into stationary ones are reversible (usually differencing, log-transformations and alike), thus the predictions can be applied back to the original time series.

Treating time as a first-class component really just means to factor in the absolute point in time into the models at training time. This only makes sense if the absolute time changes properties of the distribution that cannot be accounted for with regular transformations. If that's the case, then we assume that these changes cannot be modeled, and are thus either random or follow a complicated systematic we can't grasp. In the first case, a NN wouldn't improve either, in the second case, we either need to always use the full history of the time series to make a prediction, or hope that a complex NN like LSTM might capture the systematic.

In any case, I think one of the more compelling reasons to use NN is to not have to do preprocessing. The trade-off is that you end up with a complicated solution compared to the six or so easy-to-understand parameters a SARIMA model might give you. And the latter even might give you some interpretable intuition for the behavior of the process.

</comment></comment><comment><USER11> My very first move with timeseries data is to get to frequency space as fast as I can.

<comment><USER12> Genuinely curious -- how do you create predictive time-series models in the frequency domain?

(background: control systems)

<comment><USER11> speech recognition immediately jumps to mind

<comment><USER12> Speech recognition is generally not considered a time series problem though.

<comment><USER11> what about speech is nontemporal?

<comment><USER12> Time series problems are indeed temporal, but not all temporal problems are time series problems. Time series deals with time-specific features of a discrete sequence like autocorrelation, trends, seasonality, etc. whereas frequency domain methods deal with, well, frequency.

Support you're are looking at sales patterns over a long period of time, which has certain patterns. FFTs are unlikely to tell you much that is useful or predict much whereas time series methods can reveal patterns where the t is the independent variable.

</comment></comment></comment></comment></comment></comment><comment><USER13> I mostly feel these methods are quite overkill for most applications. As a purist, I'd recommend starting out with a simple linear regression and then moving on to adding methods to cover the letters of SARIMA by showing the need for each. It may not be as flashy, but linear regression is a stupidly powerful and very cheap tool for all kinds of situations.

<comment><USER14> As a complete non-purist I'd suggest chucking the data into Auto.arima and seeing where that gets you. Not only will it save a lot of time, in my experience it tends to produce better models.

[https://cran.r-project.org/web/packages/forecast/index.html](https://cran.r-project.org/web/packages/forecast/index.html)

<comment><USER15> I saw an article which I can't remember that warned in which contexts auto.arima might not work. But in the majority of times auto.arima outperforms the old Box-Jenkins methodology.

</comment></comment></comment><comment><USER16> I really recommend Prophet as an easy to use option like the article says.

I needed anomaly detection for prometheus metrics integrated with grafana for marking "anomalous" regions so the model doesn't learn them.

Took me a week to set it all up including packaging up as a Microservice and deploying.

</comment><comment><USER4> In the multivariate time series forecasting problem i found out that fine- tuned xgboost (and its variants) performs much better than fbprophet, sarimax, RNN variations. Predicting time series with RNN is like killing a bird for bazooka.

</comment><comment><USER17> I really appreciate the philosophy of defining metric, and measuring performance going from simple to complex methods.

I've also used Prophet library, and find it works well out of the box.

</comment><comment><USER18> Gaussian Processes seems to be pretty popular, might want to include that to the comparisons.

<comment><USER19> Gaussian process is marvelous. Demos like [https://statmodeling.stat.columbia.edu/2012/06/19/slick- time...](https://statmodeling.stat.columbia.edu/2012/06/19/slick-time-series- decomposition-of-the-birthdays-data/) just seem magical.

</comment></comment><comment><USER20> Anyone patched prophet into graphite? Curious if the two are easily combined.

</comment><comment><USER21> This is one type of time series, but how about audio time series?</comment>


It took 12 weeks to ship an MVP I thought would take 3 - <AUTHOR> https://boxci.dev/blog/why-it-took-12-weeks-to-ship-an-mvp-I-thought-would-take-3 <comment><USER3> How did you manage to constrain the time overrun to only 4x?

As a mercenary engineer, I've had to answer the estimation question many times. Whenever I've given estimates, it has only ever shot me in the foot. Spolsky might have figured it out, but I haven't. So I try to avoid giving estimates as far as possible and instead focus on demonstrating velocity of a working system they can choose to stop funding at any time.

Some clients, especially from the construction industry, expect me to give them GANTT-chart style estimates down to the hour. Here is how I convey the software estimation problem to them:

If I write the same code twice, I done fucked up. So any code I write, is new code. If I can reuse code, I will, but that's not the code you're asking about. In your industry, you have built the same house many times before with the same team, on the same foundation. But you are employing me to design, architect and construct a new house that has never been built before. If it existed already, you would just buy it off the shelf instead of employing me.

So think of me as more of an architect than a labourer, and together with you as the client, we are embarking on a design that you're not quite sure you want yet, that won't collapse on a potentially unstable foundation.

<comment><USER4> Having done hundreds of small to mid sized projects I take comfort in the fact estimating is a very distinct task that even the best of developers learn last.

I've got three tricks in my pocket that at least help me with this:

The first is that I go by the formula mentioned in "The Mythical Man-Month" — which is that the effort in larger projects is distributed as follows:

1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand

Developers tend to mainly estimate their _coding_ time, which leads exactly to the effects mentioned. It also explains all the annoying situations with all the holdups once the project is "almost done", this is simply a systems test and will add another 25%.

The other is that I simply add 5-10% on top for each person involved into the project (dev, stakeholder, anything) for communication overhead. It usually holds true.

The third trick is meticuluous focus on lean delivery, which involves scoping down, early testing on as much as possible, hidden and pre-deadlines and setting tractable sub-milestones.

Unfortunately, all of these techniques don't accelerate the project, they just help you be more realistic. If you find something that accelerates complex projects, let me know ;-)

<comment><USER5> > If you find something that accelerates complex projects, let me know

Developer experience. I've been working as a developer for a living for 18 years & I thought I was pretty hot-shit 10 years ago already, but I can probably do more today in 4 days than I used to in 4 weeks (or 4 months a few years before _that_ ).

<comment><USER6> This holds very true up to the architect level.

<comment><USER7> As learning curves generally flatten out, that is to be expected.

<comment><USER5> I've switched sub-fields of development a few times during my career (scientific computing, back-end web, front-end web, desktop applications, embedded, games [various platforms - native desktop/mobile/consoles, html5, flash, etc]) and I found that helped me keep the learning curve steep.

</comment></comment></comment></comment></comment></comment><comment><USER8> I can't accurately estimate non-trivial software. I've never met anybody who can accurately estimate non-trivial software. I've never seen anybody claim to be able to accurately estimate non-trivial software. Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial.

<comment><USER9> The trick is to break it down until it's all trivial. That process takes time itself, but you can estimate that much more easily. I've recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me).

Another approach I had some success with was estimating the 80% likelihood case, I.e. I'm 80% sure I can finish this in the time I'm estimating. Less accurate, but much more predictably on schedule, which is more useful for many stakeholders.

A last one is giving rough estimates and being clear about how rough they are and how much time it will take to get more confidence. I was handed a 50 page PDF of API docs for a service and asked what the estimate was for integration. After 15 minutes I said "1-4 weeks", if you want more accuracy then I'll need a few days. The answer was "no problem, we wouldn't consider it unless it was < 1 week".

These examples are all on the weeks to low number of months scale, but the same applies further up. Having a good understanding of the codebase and domain are very useful.

Estimating isn't easy, but treat it like any skill, it can be improved. It requires some flexibility from product managers, but open communication goes a really long way and results in better decisions overall, less wasted effort.

<comment><USER10> Breaking it down until it's all trivial is the most non-trivial part of the exercise.

If everyone could do that trivially, then there would never be any problems.

<comment><USER11> Breaking tasks down is like writing another program. Plenty of tasks branch off based on their result; you end up building a task DAG and not a task list. You could try to estimate that with Monte Carlo, but in reality, you won't get the correct shape of the DAG up front anyway.

</comment></comment></comment></comment><comment><USER12> The thing about estimating is that you can't factor in the things you don't know:

\- The tool you planned to use has a bug/defect that blocks you.

\- The people who said they could give you some information you need, can't.

\- You misunderstood or were misled as to the capabilities of a tool you need.

\- The parts you need don't actually fit together as planned.

\- The documentation you were relying on is wrong.

\- A delivery you are relying on won't actually be ready on time.

\- A process that's worked every time has an unhandled edge case that you're going to trigger in this project.

\- A regression in a software package will block you because you can't use the previous version for other reasons.

The more moving parts there are, the more likely it is that one of the interface points between them will block or delay you in one of these ways, potentially for weeks, maybe even months.

So for any nontrivial project, you should expect a 2x-8x delivery inflation over your "safely padded" estimate. You have a 75% chance that you'll deliver within 2x of your padded estimate if you've made a good estimation, sliding to worse as the number of moving parts increases.

<comment><USER13> You can add personal problems that can affect focus to the list

</comment></comment><comment><USER14> Developer to self: "It'll take me about a week"

Developer to development lead: "It'll take about two weeks"

Development lead to project manager: "It'll take about 4 weeks"

Project manager to self: "It'll take double that plus 2 weeks"

Project manager to management: "It'll take 12 weeks"

Management to client: "It'll take 8 weeks"

Actual time taken: 16 weeks.

<comment><USER15> Client: Wow, this is the first project that took only 2x time. We usually anticipate 4x.

<comment><USER14> >> We usually anticipate 4x.

All software estimation boils down to the long established scientific methodology:

(2 X what the last person said) optionally plus 2 weeks

<comment><USER16> Years ago I worked with a developer who had a different methodology: 2x, then bump the unit of measure. Thus, 1 day -> 2 weeks; 2 weeks -> 4 months. It's been remarkably accurate over the past couple of decades.

<comment><USER17> 8 weeks => 16 months, 2 months => 4 years

???

Doesn't seem consistent

<comment><USER6> > 2 months => 4 years

It's consistently correct.

</comment></comment></comment></comment></comment></comment><comment><USER18> I once had a manager who insisted on time estimates, but used them in a way that I actually found valuable. You'd write out all the tasks involved in a project add them all up, and then say "this will take T"

Then he'd say, "okay, what would it take to do what you just said in T/2?" Then you'd cut stuff until you got to T/2\. The project then, very often, would take me the original T.

This seemed to work a lot better than just doubling the initial estimate to 2T.

<comment><USER19> In UI design you do this exercise where you put everything in 4 categories. Must have, should have, could have and won't have. Take your idea and jam it into these for while being 100% honest. It does the similar thing as you mentioned. But truly like the idea

<comment><USER20> MoSCoW, I learned this studying CS

</comment></comment></comment><comment><USER21> _> Sometimes it takes a conversation with someone else unfamiliar with your work to really question your fundamental principles_

This is one of my favorite tools for development. I always sketch out an idea (no coding) and then try to describe it to someone with zero CS background before diving into an mvp. The times when I didn't follow this process - <USER2> - just as op described while trying to document the cli, I basically wrote the damn thing 2-3x over. So instead of a couple hours of chatting with other people, I had to spend days/weeks running in circles around my own work. Please, if you have juniors or if you are a junior, try to drive this lesson in.

<comment><AUTHOR> Whilst working on Box CI, I've had a few conversations that have totally change my trajectory and way of thinking about the product. It's really the best thing you can do to advance things. Sitting writing code is only ever linear - you make progress one hour at a time, very slowly. A 15 minute conversation however, especially with someone you haven't talked to about it yet, can save you days of unnecessary work on something useless or, better yet, get you to an idea that might have taken weeks to come to on your own.

</comment></comment><comment><AUTHOR> OP here - this is a sidebar but the HN hug was making the page load really slowly (~10s for me) even though the blog part of the site is cached. Anyway, because I'm using kubernetes all it took to fix it was bumping the nodes in my cluster, 4x the replicas, _kubectl apply_ and it's snappy again! All done in about a minute. What an awesome tool kubernetes is.

<comment><USER22> Please take this comment in good faith because I'm genuinely curious: why do you need a kube managed cluster of N nodes (an now 4x N) to host a static blog? I wonder what works goes on under the hood that this needs such scale.

<comment><AUTHOR> The blog is just attached to the product site [https://boxci.dev](https://boxci.dev), thats the reason for using kube. Should be separately hosted but this was just simpler.

The static blog pages though are all cached via nginx so I was surprised I needed to increase the nodes & relicas. Short answer is I don't know, and will need to investigate, but I suspect it's because the kubernetes node instances themselves are fairly low powered, there's a low cpu limit on nginx, and perhaps nginx is doing a lot of work serving the js bundle to so many simultaneous users, which really should be hosted on a CDN (probably also the blog).

<comment><USER23> > Should be separately hosted but this was just simpler.

Probably shouldn't. If you are already managing an automated environment, creating another environment that is easier to manage has nearly no upside.

Unless that phrase was meant to use the CDN you talk about later, but again, do you need a CDN to solve the easiest part of your infrastructure? (Or rather, do you have enough traffic so that it isn't the easiest part?)

<comment><AUTHOR> Yeah my phrasing wasn't that clear there but I essentially meant hosted as in cached on CDN servers, just to reduce load on the nginx instances. Though my best guess at the moment for what was causing things to be slow was just sending the JS bundle to so many simultaneous users. Putting that on a CDN may be enough.

</comment></comment></comment></comment></comment><comment><USER24> I would consider myself a fairly experienced developer (~ 10 years), but yet I have had the same experience on countless occasions. People always think of you as "being the expert" knowing everything, so I try to explain my situation like this:

"Think of me more like being a journalist. You want a good story and have a rough idea, so I will find the right people and interview them (domain experts, business people), try to figure out how to distill their knowledge into something that is both accurate, yet not too detailed and most importantly has to fulfill the needs of my readers/users (easy to read, yet super insightful, with some pretty images etc.). Wheter the article is about nuclear physics or siamese koalas is secondary, the process is more or less the same, yet I am neither a koala expert nor a nuclear scientist. You are the expert."

I also try to explain why I am unsure about estimating even relatively small tasks like this:

"You know restaurant (or another famous location) Y, right? We both know how to walk, I mean we have had like 30 years of experience in doing that, correct? So how many minutes does it take you to walk from here to restaurant Y?". The more people in the group, the more interesting it might get. Estimates usually differ by a factor of 2-4. People usually cannot even correctly estimate a trivial thing like taking a walk.

<comment><AUTHOR> The walking example is really good, I also regularly underestimate how long it will take me to arrive to meet a friend walking, by public transport, whatever.

The reason it's an underestimate even when I know the distances and usual times is because I think about the ideal set of conditions (not missing train connections, clear streets for fast walking, being able to find the place we're meeting instantly on arrival rather than looking around for the entrance for 5 mins) and go with that. I never account for the possibility of missing a train connection by 15 seconds and then having to delay the journey by 30 mins. Even though I know, of course, there is a non trivial chance of that happening.

</comment></comment><comment><USER25> A colleague from a previous job once told me: "when a developer gives you an estimate, always double and add one of that unit" (estimate = 2n+1). He told me this after a while, because he would often nag me to clarify if I meant 7h or 1 day.

i.e. if you estimate 7h, then calculate 2x7+1 = 15h.

If you estimate 1d, then calculate 2x1+1 = 3d = 21h.

It's a silly joke, but it also gives insight about how we perceive time and the elasticity of estimates.

And of course, instead of multiplying by 2, you multiply by a time factor that depends on the risk factors involved (which are also guesstimates, but for me 'x2' would mean a rather low risk factor).

<comment><USER26> That sounds like a relative of a rule of thumb I read once upon a time: projects slip by the units they're estimated in. N weeks slips by weeks, days and days, months, years, etc.

</comment></comment><comment><USER27> It's astonishing how many developers resign to the idea that "estimating software projects is impossible". It's impossible when there are either,

\- Technical uncertainties (e.g. self driving cars)

\- Human uncertainties (multiple different teams building single large software system)

\- Scope uncertainties (we don't know what we are actually building until we get into the weeds)

Outside of these we should be able to make _reasonably_ accurate (+/\- 30%) estimates. I wrote a blog [1] about it if someone is interested but here are the main takeaways,

\- Don't just estimate writing code but also include time required for testing, documentation, communication, setting up infra/deployment

\- If certain part is hazy ("is there a reliable python library for speech to text") then research it enough to know the path ahead

\- Breakdown the system into smaller units until you feel confident to estimate each piece

[1] [https://blog.amirathi.com/2018/02/05/science-of-software- est...](https://blog.amirathi.com/2018/02/05/science-of-software-estimation/)

<comment><USER23> Scope uncertainty is always larger than the certain part. It's often nearly all of the scope.

Technical uncertainty is also more common than not, unless you are using a dying platform, it will change between the estimation and implementation.

Human uncertainties are an avoidable one, if you work alone. If you are in a team, they are also certain.

Or, to put it shortly, yes it's perfectly possible if you are doing a university project alone in an old platform without an active community.

</comment></comment><comment><USER28> It's hard enough to estimate accurately when you are building your own project with no one breathing down your neck. But be a contractor, where your estimate becomes your salary, and you'll find that you tend to give longer estimates.

I once gave a 3 days estimate for a client project. 2 days to make sure I build it right and a third for testing. It turned into a 7 weeks project: [https://idiallo.com/blog/18000-dollars-static-web- page](https://idiallo.com/blog/18000-dollars-static-web-page)

</comment><comment><USER29> I really wish the estimation process would get turned around. Let stakeholders decide when they need it, and engineers are responsible for delivering the best version they can on that date. As the project unfolds, stay in close communication and make timely decisions about what tradeoffs are acceptable.

My estimates get accurate once I know where we are on the spectrum from quick and dirty to pushing the boundaries of what's possible. There's a 3 month version and a 3 year version of a lot of ideas.

<comment><USER30> That's the idea driving agile product development: defining and estimating big projects is hard, so let's do many small projects (sprints). If the stakeholders have a hard deadline, you can ship whatever you have then because your product is supposed to be in a shippable state, though possibly with reduced functionality, at the end of each sprint.

</comment></comment><comment><USER31> Aty place we don't estimate time at all. It's nearly impossible. But value of the fix or feature is loads easier to estimate and measure. Bug $X is worth $10000, dedicated $5000 to fix it. Check progress. Dev says almost done? One more cycle. Still seems far? Punt.

I'm always confounded when managers want a time estimate but cannot provide a value estimate.

The goal is the same: fix important/urgent bugs, develop product and keep good close velocity.

</comment><comment><USER32> Thanks for sharing, I just quit my sideproject after a year of coding and find posts like this helpful to learn from that experience.

> Then I stopped, took a step back and looked at the product from the > perspective of someone who would want to pay for it.

Though I think this is dangerous advise. You do not know what this perspective is like (unless maybe when your product is a "scratching your own itch"-type product) and therefor making design changes makes no sense. You will never know if users maybe even preferred your first "design", or that there is a different blocker like landing-page, installation-instructions or anything really preventing them from starting using it.

<comment><AUTHOR> Thanks for saying that as it's basically the reason I wrote the post. Really good to share these lessons with fellow bootstrappers as so many of them are general and applicable between projects, even whole businesses.

Totally agree with what you're saying here and let's see, I might write another post in a few months essentially saying this was a mistake and a waste of time, but yeah if you're interested in seeing a comparison, check out the twitter account for the blog @zero_startup and you can see the old screenshots and the newer ones.

</comment></comment><comment><USER33> As my colleague says: The time where you know the least about a project is when you start. This is also the time when your estimates are likely to be the worst.

When can you say with fairly good certainty how much longer it's likely to take? In my experience it's about 1/3 the way through the project. I'll give you my reasoning behind this number.

There is a model of software defect discovery called Littlewood's model. It basically says that the rate of software defect discovery is a random variable. As you discover more defects in the code, the number of defects that are left to discover diminish. Assuming you put in a constant effort to discover defects, your rate of discovery decreases. You can estimate the number of defects left in the software, by looking at the decrease in discovery rates over time. There are lots of scholarly articles on Littlewood's model, so I won't go into more detail than that. There are newer models too, but I always found Littewood's "good enough" for my purposes.

It occurred to me that requirement discovery might follow a similar curve. As time goes on and you understand more and more about what you need, the number of things to discover decreases. If you work on your project in a constant manner, the rate at which you discover new requirements will decrease over time. I took data for a number of project and the discovery rate curves were very similar to defect discovery rate curves.

The key is to look at the rate of change of discovery. Once it is tailing off, you can estimate the speed of the drop and get a good idea of how much work you have left to do. Each curve is different depending on a number of factors, but by the time you are about 1/3 the way through the curve, you have enough information to estimate the parameters.

Note: Littlewood's model doesn't actually hit zero, but you can set a threshold that is "close enough to zero". Where you place it will change the 1/3 figure, but I hope what I'm saying is understandable.

</comment><comment><USER34> In my career I have estimated a lot of project. I tried different techniques and I find [https://en.wikipedia.org/wiki/Program_evaluation_and_review_...](https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique) is the most accurate one.

If I was asked to give some hints, I would say:

\- in optimistic and pessimistic cases don't fear to use extreme values

\- don't estimate on your own, take reasonable amount of developers with variety of experiences

\- don't give exact value to client, give probabilities ("it is very likely that we will be deliver this in between X and Y man-hours/days)

All estimates I made using PERT were quite accurate (<5% time difference between estimated and real execution)

<comment><USER35> Yes. I was about to link this too.

From my experiences, I've found that 3x my initial "estimate / goal / ego trip timeline" gives the most realistic picture. Sometimes I can hit my best; most often things come up. It took a little while to accept, mostly because I wanted to do my best always and be able to promise and fulfill it. But Reality hit back, and I had to adjust.

It's hard to see the network effects of each micro-interaction in long range projecting, but once you really break down how long each thing could take, how that would affect each other related part, and who/what else is involved at each step/layer, it clears up the fog.

[https://en.wikipedia.org/wiki/Fog_of_war#Military](https://en.wikipedia.org/wiki/Fog_of_war#Military)

</comment></comment><comment><USER36> Being asked "how long will it take?" is actually my greatest fear in tech work. Give me long enough and I'm (fairly) confident I can overcome any other problem, but estimating time, even for seemingly trivial things…

<gulp>

I'll probably give everyone an upvote here as a) it's nice to see I'm not alone, and b) there's some really good tips.

Not sure why every tech interview introduces a whiteboard with an algorithm problem when all they have to do is ask me "how long will this simple command line client take to build" to really see the difference between the way I attack a difficult problem!

</comment><comment><USER37> Im 18 months into a project i thought would take 6. Why? Co founder bailed and i took some shortcuts early on to try and secure some clients that fell through, those shortcuts led to a substantial rewrite.

</comment><comment><USER38> I agreed with everything right up until the "extra time for design" section. I spent last year building a startup and have thought a lot about MVPs. Coming from a background of building big expensive systems, it took a lot to shake the mindset of "do it right from the ground up". My cofounder did a great job at pushing me towards the absolute minimal solution to learn what we wanted to learn - I don't need to spin up a backend and write CSS, I can use Wix to mock it up and see how that goes, THEN build it properly.

The idea is to learn as much as possible (read The Lean Startup if you haven't). If you build too much in one go, you're going to have tied yourself to one vision of how your users will use the product and be more closed to learning from them what they actually need. Note that you were persuaded by a _designer_ to make the design nicer, not a user, potential user or even product manager.

What was the problem with launching, and then deciding that design was the next priority and working on it while your product was running?

[disclaimer: I definitely haven't got this figured out as we shutdown the company and I'm back building Big Expensive Systems]

<comment><AUTHOR> > What was the problem with launching, and then deciding that design was the > next priority and working on it while your product was running?

Great question, and one I asked myself when I was about 2 weeks into the redesign :-)

On reflection, basically no, you're right, there was no reason I couldn't have shipped and then improved the design in the meantime. The thing about it not being good enough for people to pay for was just my opinion - not tested with real customers.

</comment></comment><comment><USER39> My personal experience is that traditional software estimation techniques don't work when done for a MVP situation. Yes it's frustrating like hell to not know how long before your money, patience and interest runs out. In a non MVP situation some estimation models work, some 40% of time. But managers make it look like they work all the time. Cutting scope to hit deadline doesn't count.

<comment><USER39> Also the Viable part of MVP is subjective. As you build the MVP, your idea of what is viable changes. This needs to be accounted for. The minimum product has to be viable for a paying customer. If the MVP is not a paid product the you can get away with less polish, not so with paid products.

<comment><AUTHOR> Exactly what happened with Box CI :-)

The _viable_ I had in mind was 'it works' \- later realised that actually viable was 'I think there is a chance I can ask people to pay for this' \- turned out that second part around doubled the already overrun build time!

</comment></comment></comment><comment><USER40> Yep. Me and my boss estimated rewriting what looks like a really simple Silverlight application in HTML5 in about 3 months time. He's far better at estimating than I am, and a year later we finally did it. Problem was we chose to use .NET Core cause it was more modern, and who knows if Microsoft will dump .NET Framework at some point (and honestly after .NET Core 3.0 I could finally see this being possible). So we upgraded to .NET Core.

Estimating requires you already understand the very thing you're estimating. This is why plumbers, and electricians give you reasonable estimates. Heck when we hired movers after buying our first home they estimated two hours, and were done just a few minutes before the 2 hour mark on the spot.

The issue with programming is, your tools change, your approach changes with new iterations (usually for the better!) and you notice new problems, or sometimes you do one thing in 5 minutes, and your second run through using a similar approach is broken because it requires an edge case you didn't anticipate code wise.

</comment><comment><USER41> I've gotten pretty close with two 4 months projects this year (2 weeks off in both cases). It took two weeks of planning, research, and understanding roadblocks to get to that point.

It's doable, really, and it feels an awful lot like waterfall when you're in the moment. The most important steps were:

1\. Write it down 2\. Don't keep it to yourself

Everyone else is smarter than me and provided immeasurably good feedback.

<comment><AUTHOR> 2 is really helpful, 100% agree.

I shared my deadlines and progress on this build via the blog and on twitter under @zero_startup and I would say doing that probably pushed me to ship the MVP at least 50% faster.

</comment></comment><comment><USER42> Man your telling me. I planned on spending 4 months on [https://appdoctor.io](https://appdoctor.io) and ended up launching it after 1 year and 2 months.

<comment><AUTHOR> Have heard so many stories like this. It's unbelievable how much longer these things can take compared to what you think at the idea stage. How's it going now?

</comment></comment><comment><USER43> "What's the idea for Box CI? A CI service that does everything for you, except for running the builds."

Marketing advice: define "CI" near the top of the first page. The word "Integration" is not on the page either. I am familiar with Continuous Integration but not the abbreviation CI.

Adding to the confusion, the font on (most of) the home page is sans serif, so CI cee-eye looks like Cl cee-ell.

Moreover, you mention CLI on the page... though I did know what that is!

Good luck with it.

<comment><AUTHOR> Thanks for this. Yeah you're right - it's that thing of when you are so focused on something for ages, lots of things about it seem obvious to you that aren't necessarily at all to other people coming in cold. This is useful feedback.

</comment></comment><comment><USER44> Is there any well-regarded book, study, methodology or even individual who claims that the development time of non-trivial software can be accurately estimated?

</comment><comment><USER45> Interesting writeup! Thanks for sharing.

>Seems easy right - it's a CLI - just document every option and you're done in half a day. That's what I thought too.

>But then you realise that each individual option is its own thing that requires thought to explain, and crucially, interacts with all other options. It's not enough to explain it in isolation. You need to tie everything together. You need examples. You realise from doing all this that there's a simpler way to name or combine options, you go back and make that change and have to update all the examples, explanations, etc.

You question whether your MVP at that stage was viable, but when I read this, I wondered whether it was actually _minimum_. Is it possible that you added too many options and your MVP would have been easier to ship if it had been more limited in scope?

>The product did not look like something anyone would want to pay for

One pitfall to look out for is that you probably can't accurately predict what customers pay for until you talk to a real customer. Maybe things like aesthetics that _seem_ important wouldn't actually be important to a customer if your product solves their problem. A designer gave you feedback, and they no doubt have valid expertise, but they're also not your customer.

I had the experience of shipping too late last year:

[https://mtlynch.io/shipping-too-late/](https://mtlynch.io/shipping-too-late/)

tl;dr of my takeaways:

* Even if you've been warned about startup pitfalls a million times, sometimes you just have to make the same mistake to learn it.

* The goal of the MVP should be to get something in the customer's hands ASAP so you can hear their feedback. If you focus on polish and design, you might be polishing something that nobody wants.

* Question whether your "must haves" are actually just ways of delaying scary conversations with customers.

<comment><USER46> Yep, the good old "build it and they'll come" trap for the naive engineer that I've stepped into myself. Thankfully, having read Rob Walling's book now I know that marketing comes before code: [https://news.ycombinator.com/user?id=rwalling](https://news.ycombinator.com/user?id=rwalling)

It's a bit dated now, but most of the advice is still relevant to solo engineers looking to turn solo founders.

<comment><USER45> I like that book too! I wish I had read it before shipping that first MVP.

My notes: [https://mtlynch.io/book-reports/start-small-stay- small/](https://mtlynch.io/book-reports/start-small-stay-small/)

<comment><AUTHOR> Follow up to my other comment, read your post and it's extremely entertaining - found myself laughing at (you can probably guess) the estimates part and a lot of the other stuff in there I know so well I felt almost as though you were writing my own thoughts better than I could :-)

Very cool to hear from other bootstrappers / solo founders like yourself talking about things they've done, successes yes but also failures and lessons, and that was also my aim with this post. I feel like it's a pretty small niche within the much larger overall 'startup' world.

<comment><USER45> Oh, thanks! I'm glad you liked it.

</comment></comment></comment></comment></comment><comment><USER47> Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

</comment><comment><USER48> Army place we point stories, Fibonacci series. Works to help identify a thing over an 8 usually needs to be broken down further. 5 and 8 are pairing stories,1 and 2 for when you have a half day available (depending on the seniority of the dev) or for a Friday afternoon if you finish another ticket.

</comment><comment><USER49> I think most programmers tend to do their estimates in this wonderful parallel dimension where the code base they will be working on is pristine, with well- designed, documented and thoroughly tested code that they get to work on without interruptions or meetings of any kind.

<comment><AUTHOR> The thing is in this case I'm building this thing from scratch on my own, so literally without interruptions or meetings of any kind, and all the code, architecture, devops, everything is exactly how I want it, and the estimate is still wildly wrong :-)

</comment></comment><comment><USER50> That's why, when people ask me to estimate work, I tell them that if they need a hard deadline things will (counterintuitively) take much longer, and try to convince them that hard deadlines are bullshit. If you want a hard deadline, I have no choice but to allocate a huge amount of buffer time, at least twice the "aggressive" estimate so that if shit doesn't go as planned (which is what usually happens) I don't miss the deadline. And I have to plan for the worst possible kind of excrement hitting the fan, which is not realistic. And then, in spite of that, people are still under more stress, because procrastination being in human nature, hard shit gets done last, and there's more in it that can go wrong.

Consider instead shipping stuff incrementally, feature by feature, when features are done, without any hard deadlines. Both the speed of delivery and quality will be improved compared to hard deadline driven development.

Plans are worthless. Planning is indispensable.

</comment><comment><USER51> I think it depends I work on a large enterprise product we are generally within 20% of the estimate. If some prominent team members were not aggressive in planing that figure would be smaller. Average age on the team is over 40 avg experience around 20 years.

<comment><USER52> Experience makes a huge difference in planning simply due to know where all bodies are buried and where dead bodies will emerge.

</comment></comment><comment><USER53> so basically all the common reasons why every deadline is missed. nothing new here.

</comment><comment><USER54> I started multiplying estimates by 3 and found it to be, in general, much closer to reality once all was said and done.

</comment><comment><USER55> What is an MVP?

<comment><USER56> Minimum viable product.

[https://en.wikipedia.org/wiki/Minimum_viable_product](https://en.wikipedia.org/wiki/Minimum_viable_product)

</comment></comment><comment><USER57> You're pretty fast.

</comment><comment><USER58> Viability is a KPI and not a set of requirements for some product.

You can't plan for a product to be viable. You first build a product and then you verify whether it is viable. At best you can formulate a hypothesis about what set of features you think is good enough in terms of KPIs and then plan to build only that. However, you have to factor in the likelihood that your hypothesis is wrong and also that the process of building something should result in refining that hypothesis over time. If that doesn't happen, you are not learning and you are probably not really building a viable thing.

The fastest way to get to viability is to take baby steps: short sprints/iterations, ship often, re-assess where you are every step of the way. Do the most valuable/risky/uncertain things as early as you can so you can adjust course if your assumptions about their value turn out wrong. Most startups get this wrong and fail for this reason because by the time they figure out they are on the wrong track they've already wasted most of their seed funding on building pointless things.

The lean movement tends to focus on the M part too much which has a built in risk for products to be unexciting and ultimately non viable. It's great if you are copying somebody else's business model or building some kind of market place. It's not so great if you are trying to do something new.

Lean has a tendency to postpone value creation until you've built a lot of low value commonalities like a login system, user management or crap like that that every startup seems to spend ages on without getting it really right. If you hear the words MVP and Android IOS and web in one sentence that translates as we're building a lot of common functionality three times and all our experiments have 3x the cost. The chances of that being utterly unremarkable and non viable are huge.

The minimal thing would be to postpone that stuff until you have something worth logging into and worth having multiple implementations of on multiple platforms. Building a good mobile experience is a huge investment. Don't even think about it until you have something viable.

You are not proving the viability of a login system with your MVP nor are you proving the viability of a slick IOS experience. Your thing is viable if despite obvious UX and feature issues you still get positive KPIs. Once you get there, you can justify the expense of making it better. So spend as little time as you can on stuff like that instead of making it the top priority in your first iterations.

As long as you are doing minimal things you are not actually creating a lot of value. You are actually postponing value creation and viability. It's the hardest things that create the most value and that are the hardest to plan and the easiest to postpone when planning. Therefore I believe, Scrum is the wrong process for building something that has a high risk/reward balance and the right process for building something that has low risk/rewards. All the value is in the stories that everybody struggles to estimate. Scrum results in most resources getting sucked up by the least valuable stuff.

</comment><comment><USER59> nice way for marketing. You could have posted a SHOW HN a thousand times and nobody would care, but this is creative way for a succesful SHOW HN

</comment><comment><USER60> This is one of the core reasons why we've built [https://saasify.sh](https://saasify.sh), an extremely simple solution to launch FaaS-based businesses and start validating product / market fit in hours instead of months.

I agree with the author in terms of estimates and their assessment of the process, but the point I'd like to make is that the vast majority of those 12 weeks it took them to launch the MVP weren't spent on core, differentiating functionality, but rather on boilerplate that's common to every SaaS product.

Important but non-core features like billing, accounts, documentation, and a marketing site end up causing many projects like this to fail before they even get launched.

If you can launch MVPs like this significantly quicker albeit in a more constrained yet platform-agnostic way (e.g., using serverless functions as an abstraction), it becomes really powerful for makers like the author of this article to focus on core value and ship quickly instead of wasting time on all of this other stuff.</comment>