251–260 of 462 posts
You'd have an Android team, an iOS team, a couple teams working on core APIs and infrastructure. Ideal team size is about five.
I looked at it this way. The thing most engineers, hero's or not, want to work on is new projects and to build products customers enjoy. The last thing they want to work on is maintenance. In my last personally owned company, small as we were, the engineering team and I documented how things worked as part of what we did every day. We found that by having the inner workings documented so that anyone in the team could…
In my experience this is the hardest part. Can't count how many times my team started documenting and then slowly, for one or the other reason, the documentation became outdated.
The cycle is: Meetings for communication -> becomes too cumbersome and time consuming -> implement policy to document things -> everyone start documenting (for a month or two) -> docs are not up-to-date because people forget/leave etc.. -> go back to meetings
I looked at it this way. The thing most engineers, hero's or not, want to work on is new projects and to build products customers enjoy. The last thing they want to work on is maintenance. In my last personally owned company, small as we were, the engineering team and I documented how things worked as part of what we did every day. We found that by having the inner workings documented so that anyone in the team could…
This is ~our approach, but it seemed to stop after ~150 employees or so.
(You also seem to have the time to write the docs…)
Earlier quoted context omitted.
So make sure you're hiring a hero and not a primadonna?
The difference between hero or primadonna can be environmental. When there are multiple experts for a department/tech stack, you get heroes. If the bus number is one, a hero risks converting to a primadonna.
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…
Amen to that!
Earlier quoted context omitted.
Because it needs to be built, supported, etc.?
Does it? Dumbphones from 30+ years ago can still send SMS messages just fine with zero software updates. Maybe once a decade or so that could have been enhanced with longer messages, pictures etc. But overall the messaging problem really should have been solved by now.
Earlier quoted context omitted.
Why is this being downvoted? Whatsapp is notoriously "just" a highly-optimized fork of ejabberd [0]. ejabberd is written in Erlang/OTP which enables quasi-horizontal scaling and amazing failure recovery, along with incredible uptime. What's different about Whatsapp compared to a traditional XMPP experience is: - it uses a single centralized server, without federating - it uses phone numbers as identifiers instead of…
Doesn't anybody remember how literally Whatsapp's founder wrote on one of the ejabberd mailing lists with something like "I just installed the server, please help me configure authentication" or the like? Retrospectively that has always colored my perception of how relevant technical aspects are for a successful startup (i.e. not much). Marketing (and viral, user-capturing & monopolist practices) are (sadly) much mor…
They not only used FreeBSD for their servers, their CEO at the time Jan Koum donated $1 million dollars to FreeBSD foundation too. Talk about giving back! The only thing they failed at was making money. I really wished they had. They knew what Whatsapp meant to the world. Look at WA now. https://freebsdfoundation.blogspot.com/2014/11/freebsd-found...
You can very easily build your own WhatsApp server today by simply deploying https://www.ejabberd.im/ on a box and using https://conversations.im/ on an Android phone.
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…