TIL, 2017-04-25

Game changer: https://github.com/gothinkster/realworld.
Date.today.all_day is a thing.
gem environment.
gem pristine.

Jelly Vision

When creating OSS, it usually is just a side project and not making it a major/full time thing.
Consultantware: When you need a consultant for the software.
Rails is a toolbox.
Good OSS projects need good marketing. Marketing is about communicating your story. Out-teaching instead of out-spending. I want to out-market any other web framework. Picking an enemy: we picked on Java when we were marketing Rails.
Other programming frameworks are depressingly bad (in that they are not good for the programmer that was using it).
I think the 10x thing is with deciding what to do. What to program. What features do we need. High productivity people know the 7 hour implementation, not the 100 hour implementation.
When it comes to software, I have a low bar in terms of ambition level. Sometimes what I have to do is just a little bit better. A part of being productive is making 40 hours count. If I have to work more than 40 hours to do the things I want to do, it’s probably not that valuable anyway.
I want to sink my time into a moderately ambitious project that is going to ship.
Rails has a very large tent. I accept that we aren’t all going to agree all the time. Good ideas bubble up.
Common mistakes by OSS: being too ambitious, not marketing things. Thinking that most projects are about technology, not about people. You have to manage people. Not recognizing the limits that one person can do. Big tent means more than one people means managing people.

Basecamp

Basecamp is the thing that we have always worked on, but no one knew it anyway.
Just focusing on one thing brings clarity to what we are doing.
Over the years, we’ve built job boards, books, products. There are a lot of plates to juggle.
David and I had 2 new products, it’s one thing to make a product but it’s another to market etc. We don’t want to hire more people. That’s totally fine, but its not our direction.
Disadvantage: Letting go of products.
When something is interesting, you shouldn’t have a long runway for it.
Things tend to bubble up/are organic. We have formalized the process (pitch day), we have a lot of cool ideas but we weren’t able to pitch it. People feel good that they had the opportunity to explore something new.
We do very little traditional user testing. We test stuff ourselves/we have a good QA team that make things better. We roll 10% of our customers first. We’ve began customer interviews but not about features, about customer stories. We don’t ask the traditional HCI questions. There is no context. I would rather hear the story of what they are trying to do, not the features they want.
Very rarely is it that people don’t want to use Basecamp because of a lack of features. We would be chasing little things if we concentrated on tweaking features.
Calendar: Maybe the solution to your problem doesn’t need a calendar? One of the biggest problems with Basecamp is getting people to do it with you. Could we improve our invitations, or could we just make it so that you can share things you do with another person?
Some feature requests are very personal. Priority assignments on todos: well just reorder them? Is this really the thing that causes a person problems? We try to act not on the request of somebody, but on their behalf.
“Legacy” systems just have a bad meaning for our industry. You can reframe this using the word “stability”. For software makers, your software is not the most important thing to the people that use it.
The inconvenience from Basecamp classic is good since these are the customers that don’t want it to change.
We have few traditional meetings, but we meet though. We use Campfire which is a real-time chat where people can go in and out. We find that there’s more communication so we don’t need to do the big meetings.
When you have 3-4 people working on something, the comm channels are pretty strong. You’re talking all the time/meeting. We do get together from time to time and have chats.
Meetings are just a poor tool for productivity. Meetings are usually like: someone has to say something to someone. Could this have just been an email? Could this have just been a todo-list? It feels like working but it really isn’t.
Direct competitors: Email and people meeting up. There are so many things that prevent people from using any piece of software. The customers that we want to get are the “I don’t trust software” or “I have a lot of things to do”.
People hear software from other people. I want the experience to be people sharing the app with other people.
Things haven’t really change that much since the first iterations of Basecamp. The fundamentals of Amazon are “I want to get my shit faster”, so they invested in distribution centers.
People have low expectations for support. For support, we respond to emails in 1 minute, we hired people to be on support. Support quality is not going to change and people want this regardless.
In 1952, people complained about technology.
A good feature is treating people well. At the end of the day, if you feel like shit when you buy from a company, you will probably hate that company.
People value interaction and employee attitude. I am not leaving someone who takes care of me. If we get back to the basics of treating people well, then we don’t have to compete on features. This is a feature.
Basecamp: We’re trying to get people to make progress. When you want the world or people to progress/we can help somebody, I’ve feel like I’ve made the dent in the universe.
I like Basecamp and I like going to Basecamp and I like to work with people who are interesting and intelligent and kind and nice. I like making software. I like making impact in our way. I cannot work somewhere where I don’t believe in the people and I don’t want to create the place for others.
I don’t really have a purpose. I just like to make stuff.