I run a profitable SaaS business on Haskell and Elm that I developed on evenings and weekends. The technology is my not-well-guarded secret to serious productivity. I also run another startup (recently released, not yet making money), again on Haskell and Elm, with a business partner (though I did all the programming).
I’m not a great programmer, but it’s some hilarious joke that I can build two businesses from scratch on my own on evenings and weekends faster than a team of 10 developers can implement one feature in an existing codebase with Clojure and ClojureScript at my day job.
I’m not doubting that you might be getting some benefit from your technology choices, but a single reasonably skilled and sufficiently motivated person will always outpace a team of 10. The team might beat you on longevity and stability, though.
Do you have any more data points on that? I don’t assume you’re wrong, but this idea has interesting implications for me when I start hiring some people for a different VC-funded project I’m running. As I understand it, conventional wisdom is that more workers results in more labour/results, and I’ll need some solid data to convince other people that this is a myth. Is it just The Mythical Man-Month that I should read?
As I was reading your comment, all I could think of was “read the Mythical Man Month”. Read it all, but specifically the essay “Out of the Tar Pit”. The short answer is that it depends on what you are trying to build. To get a program to market, generally a small team will out-perform a large team. As the product grows, there are divergent thoughts about how to build effectively. Many have bright shining stars they will hold out as proof that their way is the best way and plenty of counter-examples about how others failed. To my knowledge, there is no silver bullet (also in the mythical man month) but a process of finding what works for your organization.
I joined a Haskell company as well. Early this year, in fact. Like you it was quite challenging in the beginning, to get up to speed with Haskell way of doing things.
Strongly agree that knowing different languages is great! I work mainly with functional programming and recently I learned about purely functional objects with recursive types and it blew my mind! I had forgotten about OOP after obsessing a bit about Haskell.
I run a profitable SaaS business on Haskell and Elm that I developed on evenings and weekends. The technology is my not-well-guarded secret to serious productivity. I also run another startup (recently released, not yet making money), again on Haskell and Elm, with a business partner (though I did all the programming).
I’m not a great programmer, but it’s some hilarious joke that I can build two businesses from scratch on my own on evenings and weekends faster than a team of 10 developers can implement one feature in an existing codebase with Clojure and ClojureScript at my day job.
Would love to see a detailed write up of how you did it - the stack, the tradeoffs, the tooling to take it to prod.
I’m not doubting that you might be getting some benefit from your technology choices, but a single reasonably skilled and sufficiently motivated person will always outpace a team of 10. The team might beat you on longevity and stability, though.
Do you have any more data points on that? I don’t assume you’re wrong, but this idea has interesting implications for me when I start hiring some people for a different VC-funded project I’m running. As I understand it, conventional wisdom is that more workers results in more labour/results, and I’ll need some solid data to convince other people that this is a myth. Is it just The Mythical Man-Month that I should read?
As I was reading your comment, all I could think of was “read the Mythical Man Month”. Read it all, but specifically the essay “Out of the Tar Pit”. The short answer is that it depends on what you are trying to build. To get a program to market, generally a small team will out-perform a large team. As the product grows, there are divergent thoughts about how to build effectively. Many have bright shining stars they will hold out as proof that their way is the best way and plenty of counter-examples about how others failed. To my knowledge, there is no silver bullet (also in the mythical man month) but a process of finding what works for your organization.
I joined a Haskell company as well. Early this year, in fact. Like you it was quite challenging in the beginning, to get up to speed with Haskell way of doing things.
Strongly agree that knowing different languages is great! I work mainly with functional programming and recently I learned about purely functional objects with recursive types and it blew my mind! I had forgotten about OOP after obsessing a bit about Haskell.