ToJans

We build tools like that over at https://virtualsaleslab.com. Not open source unfortunately...

FYI I tried building something similar running completely client-side a little while ago; I did not get very far TBH: http://users.telenet.be/bull/sudoku/ As for solving the sudoku: that's the easy part: https://github.com/ToJans/learninghaskell/blob/master/0003Su...

I can't help but notice that slack is starting to get "enterprise" (threaded comments, this username thingy, ... ). They seem to be introducing a lot of complexity for all of the users, while only some of them would benefit from these new features. I'm hoping that they start realizing this, and keep simple chat the default, while allowing you to opt-in for all these "handy" features...

I have no idea what the product manager was thinking here... Can someone elaborate why this "feature" - which implies potentially a lot of confusion - benefits most users?

+1

This makes me wonder why this hasn't been used in more cases... I have been messing around with parametric 3D models using regular 3D vectors, but getting to the bottom of this might make my life a lot easier.

For custom JSON schemas nothing tops F#'s type providers [0] IMO.

[0] https://github.com/jet/JsonSchemaProvider

First:

> Elm has an incredibly powerful type system

Near the end of the article:

>Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application.

IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e.

  {-# LANGUAGE DeriveGeneric #-}
  
  import GHC.Generics
  
  data Person = Person {
        name :: Text
      , age  :: Int
      } deriving (Generic, Show)
  
  instance ToJSON Person
  instance FromJSON Person

While I understand Evan's aversion against complexity, it makes me a bit wary about using ElmLang in production. I am currently using TypeScript, but if I would need a more powerful type system, I would probably switch to Haskell/PureScript or OCaml/BuckleScript instead.

While it has a nice atmosphere, I don't see what makes it special enough to be featured on hacker news? It looks just like a simple vertex shader to me TBH, or an I missing something blatantly obvious here?

I think luck and timing make sense from a VC point of view, but when you are on the other side, it feels slightly different: as a founder, you need to have a vision about your future consumers within 5 to 10 years, even before you are laying down the first brick... It needs to be so obvious and in your face that you can sell it effortlessly to others (including VC's and your prospects). You start from a gazillion ideas and hunches, and after a while some will keep emerging until they will evolve into a vision. You pick some of those ideas and try to assess them, to figure out if you are stuck in your own bubble, or are really on to something. To me it's a little bit like Thoughtworks' tech radar: adopt, trial, assess and hold. Once you've made your choice, one of the most important things IME is that you need to be able to adapt that vision based on customer feedback. By the time you're in that phase, it might look like it's sheer luck and timing, but I honestly believe that all the grunt work and preparation you did increase the odds to succeed big-time...

I wouldn't bet the house on a single horse; f.e. what it Microsoft suggests another todo app? One plan isn't enough IMO; you should have at least 5, or even 10? The odds of one plan failing are a lot bigger than the odds of all of them failing. It's all a numbers game IMO. I prefer to throw stuff at the wall and see what sticks. One of our more successful blog posts literally took me 2 minutes, while we have others that took over a day and didn't work at all...

Thanks for the tip!

Find an entry into a market, and don't offer the world, but figure it their most painful integration point and fix that. Find multiple customers for that single integration point before you even start building anything. You need to learn to walk before you can start running: baby steps and validation after every step make sure that you only risk wasting your last step, as opposed to the whole journey.

Pick a niche market: hairdressers, dentists,...

Setup a customised website/landing page directly targeted at these people from your home town and try to get their attention and feedback. Be polite but determined: send an email, call over the phone and meetup.

Selling a generic product nobody knows is hard, so try to become #1 in your vicinity for a certain niche, and make sure all your marketing material is focused on that niche. Once you're the reference in that niche expand vertically or horizontally. Repeat ad infinitum. Combine your outbound marketing with proper inbound marketing, and after a while you'll gain traction and leads will start dripping in slowly but consistent.

Don't offer free trails, but tell them they can get your product at a reduced rate forever. Free customers are hard to convert to paying customers, so charge them something (even if it's peanuts). You can always upsell later.

Gradually increase your prices for your new customers as you expand your market. Keep old customers at their old price; it will take them feel special and reduce churn. At the perfect price point people will complain it's too expensive, but buy anyway.

After you've done this (I'd assume it will take anywhere from 6 months to a year) you will probably already have a long term vision in how to proceed.

This is a common mistake: building a product based on assumptions, and not on the market's demand. I've learned not to add a feature before I have someone who paid an advance. Secondly: your product might be to overwhelming and doing to much; experience has thought me that complicated products are a though sell. Try to reduce it to it's most basic use-case, and sell that (a simple app that doesn't require any explanation at all). Once you have paying customers you'll be able to upsell by offering your more advanced features. People are reluctant to change, so you need to expose them gradually.

Regarding the blog post: it's simply a numbers game: the odds that one of a hundred articles picks up momentum is way larger then the odds of one blog post picking up momentum. Sometimes it's better to spend the time you'd invest in one great article on ten articles instead. Or write a hundred great articles, and you're very likely to have success.

Regarding the marketing part: if my own start-up learned me anything, it's that great marketing can launch a mediocre product, but if you have mediocre marketing, your product will need to be extremely good to gain any traction.

TL;DR: business requires hard work, and shortcuts usually don't work. Outliers and survivorship bias apply to the posts that claim otherwise.

I always use factor 3.

I just think: based on what I know now, how long would it probably take to write it - optimistic -?

Multiplying this by 3 is justified by the unknown unknows, bugfixing, communication, changing scope and assuming stuff is more simple than it actually is.

Works like a charm for me in most cases.

For problems where the solution is still unknown, I tend to break it up in small cycles, with a best-case estimate. At the end of every cycle we adjust and align, so that the customer can decide for himself whether to proceed, restart or abort.

> It means we do Agile. Everything is in a flat structure, except when it comes to salary and responsibilities.

Pure gold!

I like the minimalist approach. I could probably use this to spike a few prototypes quickly, but I see one caveat: the lack of 2-way binding...

While I understand that 2-way binding might complicate everything, it is the one feature I need the most when setting up a quick-and-dirty prototype. IMHO this might be the deal-breaker...

When I was freelancing, I was specialized in fixing businesses/projects that got stuck due to tech debt and non-communicating teams, using a bottom-up approach.

The hardest part is changing the mentality of the team, but within a month or 3 you usually ignite the spark that gets everything back on track. Getting to the first tiny win that changes the status quo requires a lot of hard work, but once that's rolling, it's only a matter of making yourself redundant.

One caveat: the bottom-up approach works best when people introduce you as the helping-hand dev. Some people had a hard time understanding the exorbitant paycheck, when all you do is sit with the developers, not even being a PM? (TBH I've been an ad-interim PM in most of these projects for a few weeks, and it usually helps - lead by example etc).

TL;DR: businesses/teams do get stuck, and a consultant who knows what he's doing and doesn't care for titles can turn around things.

EDIT: The one thing that's lacking in this article, is the social aspect. If you are only fixing code, you are just fixing the symptoms, not the causes.

Process never trumps communication. IME speaking up is a valid approach. If you can't convince management either you are wrong, or the management is (you might not know the whole story, f.e. cash flow issues and knowing you can only close a client if you have feature y). Figure out what the situation is, and either realize you were wrong, try to convince them with better arguments or GTFO.

The biggest game-changer to me seems to be the last example, with `grid-template-areas`. I could probably explain this in a matter of minutes (as opposed to flexbox).

Finally an article that makes me feel confident enough to actually try using blender. In the past I have tried a number of tutorials, but the problem was they all went way too deep in the subject matter, so I was feeling overwhelmed. This one seems to give you just enough information to get going; looks like I will give it another try.

Serious question, although a bit off-topic: why is the number of Facebook/Instagram/... followers even relevant? What is the average conversion on channels like these, and aren't there more efficient channels to focus on in the beginning? F.e. go to a student event and hand out flyers there, chat with people etc?

For me this has been really useful.

While I somewhat have a noob understanding of Haskell, and some experience with monads, the parallels between composing functions (i.e. "id" & (.) ) and composing monads i.e. "return" & (<=<) never really occurred to me. Now that I've seen this, I'll probably start looking for similar patterns in other places.

This has been what made Haskell click for me: the minute you start doing something that is slightly repetitive, like a for loop including a continue/break, parallelizing code or using if error/null all the time, there's a pattern there. Haskellers recognize these patterns, and implement them once, so you can reuse them and avoid making mistakes by implementing something similar yourself every single time. Having this opportunity makes your code more shorter and concise, and instead of implementing something yourself, you can use these battle-tested implementations to model your code. (And thus avoid those annoying not-null/if error bugs for example.)

Even though Haskell might not be suitable for every problem domain, I found out it really shines by it's explicitness. You model your domain using types for intermediate states, and the exercise of converting one type to another is rather trivial. (f.e. a sudoku solver [3]).

The biggest problem for me personally has been my inability to speak the category theory language, but I'm learning... I also believe that the basic Haskell libs need examples next to their descriptions, because most of us learn by example. [1] If I can see what a maybe monad is for, I can start using it without properly understanding monads. After a while you'll have seen enough different types of monads to understand their use case. IMO one language implementer that understood this extremely well is José Valim, just take a look at the Elixir docs for data.list. [2]

Because Haskell has been mostly implemented by mathematicians and computer scientists, they assume basic upfront knowledge. This is what makes it hard for beginners. What we really need in the Haskell world is some cognitive bias mitigation. YMMV.

* [1]: https://www.reddit.com/r/haskell/comments/3rhpyq/as_a_haskel... * [2]: http://elixir-lang.org/docs/stable/elixir/List.html#function... * [3]: https://github.com/ToJans/learninghaskell/blob/master/0003%2...

Agreed... And maybe my marriage as well ;)

Greg Young did the same thing in .Net; he built a product out of it. In the end he figured out it wasn't a viable business, so he made it open source. You can download it here http://www.continuoustests.com/ and the code is OSS.

Diversity is good. When people start flocking together confirmation bias changes, so I'd assume this is not such a good thing TBH.

Is anyone familiar with Jim Colin's hedgehog concept mentioned in "Good to great" - http://en.wikipedia.org/wiki/Good_to_Great

I'd even assume it's 'inspired' by it, as they did similar studies and came to the same conclusion...

I think Nate probably uses some other way of formalizing specs, as I formulated in my blog post here: http://www.corebvba.be/blog/post/Opinion-TDD-and-startups-yo...