The way I think of it is more of taking advantage of an arbitrage (~20% discount on season tickets to face value). Instead of selling all the tickets to earn ~$2k each year, we kept and used the tickets to our benefit.
442 karma · joined August 9, 2013
Currently, I'm working to get up to 50 karma on StackOverflow so I can comment on posts! :)
The way I think of it is more of taking advantage of an arbitrage (~20% discount on season tickets to face value). Instead of selling all the tickets to earn ~$2k each year, we kept and used the tickets to our benefit.
Generally, the electron app would pull face value prices and availability from [baseballteam].com, current resale prices from hubstub.com (<- changing name) and stick them into a mini database (object store). From there, I could use these snapshots to track sales across the resale site, determine a fair value for my tickets, and estimate the probability of it selling (by comparing ticket availability between days on the resale site).
Next, I had collected a list of email addresses from friends and a few posts on Facebook and Craigslist. The app had a button create/update a Google sheet with games/prices, pull in the emails, and batch email people (in groups of <50) the information along with the games. The manual part was marking the games as sold in the sheet, tracking etransfers and sending tickets, but it was little work.
I choose my side projects more emotionally; generally based on things I'm excited about, think will be fun to make, or involve things I'm curious to learn. Happy to share more if interested.
We ended up going to 6-7 games for free, sat in MUCH better seats than we ever could have afforded to, and had access to playoff tickets at face value. Further, my friends had access to great seats at reasonable prices and I avoided having to buy from resale sites (who I detest). 90% of the process was automated.
This was a great tip given to me by a friend. I've found some amazing tools and resources because of it.
No, OP is not talking about schools in "poor emerging economies." OP is talking about their experience doing a CS degree in Kenya. The COMMENTER (telomero22) is generalizing this to be a common experience in "3rd world countries."
I'm disagreeing with the commenter, telomero22, who believes OP's experience is due to studying CS in a "3rd world country." As others have confirmed in this thread, I'm suggesting that these sentiments are extremely common with CS grade in 1st world countries such as Canada.
I couldn't disagree more with this sentiment. I live in Canada and by way of both running a tech company and working with colleges/universities here I can tell you that none of them have curriculum that's adequately connected to industry skills.
The only exception, and it's a small one, is the University of Waterloo. By way of their reputation they've built a robust internship network for the engineering students. Although they still have gaps on the curriculum side, albeit smaller gaps than other schools, students complete up to 4 internships before graduating giving them a big advantage.
- If a founder sets up a company with other people, they are both a founder and a co-founder [source](https://www.startups.com/library/expert-advice/startup-found...). It is inaccurate to say that OP is not a co-founder but rather an employee because they have less equity. It both violates the commonly accepted definition of co-founder AND if true would mean that there's no such thing as a co-founder unless equity were perfectly divided. OP is a co-founder. What it means to be an employee has its own specific meaning, too.
- In the case of startups, ownership is best determined by setting percentage ownership between founders along with a vesting schedule (i.e. when each founder will receive those shares). In OP's case, their co-founder was provided more equity.
- Control of a company, either direct or indirect, is determined by voting shares. These are not always the same as shares, but in the early stages generally are. Unless OP has the same number of voting share by way of dividing board seats equally, we can assume that all share in this company are voting shares. Therefore, co-founder likely has a controlling interest.
Therefore, OP is a co-founder. They do have ownership of the company. They likely do not have control of the company. It would be very helpful to keep this in mind when offering advice on how to approach the situation.
I'm sure there are quite a few gaps in what I've written above, I appreciate any feedback or input!
OP seems to imply that their co-founder intends to use much of the existing code base they've developed over the last 6 months for the proposed pivot. If that's the case, it doesn't seem like co-founder would be open to resigning as an employee and director and creating a new code base from scratch, especially considering that the co-founder seems to have control of the existing company.
I hope it's fair to say that you work for a direct competitor to Heroku, and that the intention of the article is to share how you've learned from the parts of Heroku that people loved and are working to build on these ideas in the work you're doing (which is great!). I'd prefer knowing that the article is written by a competitor at the start versus casually towards the end.
I hope I didn't offend you by my comment! :)
I have a MSC in Statistics, studied quantitative finance. Generally I'd agree with you. For general investing there's often little math involved other than some simple ratios and comparisons. Three numbers I look at most often are the Price-to-Sales ratio, Gross Profit %, and annual revenue growth. There's no complex math involved here at all.
Where investing does get mathy is in calculating risk. When constructing a portfolio, generally the aim is to maximize returns while minimizing risk below some threshold. There is some very interesting and fun maths involved in this process that is beyond the scope of general investing.
I'll add that many people ITT are focusing on your "boring stuff" comment. I'm a founder, and honestly, the "business stuff" is not my favourite thing to do either; particularly sales. However, it also happens to be the most important work I do. Your comment indicates that it's not something you and your co-founders believe is valuable work. I hope that's not the case, but if it is you may struggle to engage a partner with this skillset.
I want to hear about R2 on the earnings call. It's such an important part of their future, IMHO.
However, Cloudflare has 79.2% gross margin, indicating that delivering their services is highly profitable. If they ever needed more money, they could simply raise it or scale-back in other areas.
TLDR: They could go for a very long time.
This article is generally positive. The author liked the people, had a positive sentiment of the interview process, was impressed by the tech stack, had a solid manager, etc. It just wasn't the tech stack they wanted to be working with.
Super helpful.
TLDR:
- "Myth 1: Back pain is linked to having tight hamstrings"
- "Myth 2: Lying in bed is good for back pain"
- "Myth 3: My daily workouts at the gym will get rid of my back pain"
- "Myth 4: Yoga and Pilates are great ways to alleviate back pain"
- "Myth 5: Stronger muscles will cure my back pain"
- "Myth 6: Stretching is good for reducing back pain"
- "Myth 7: Having a powerful back is protective"I'll definitely have a look. Good luck!
Very happy I didn't listen to any of it.
I've been in exactly this place (big salary in big tech, started my own company). I find that these types of decisions are complex, I don't think I could capture everything in a comment, but I''d be happy to throw 30 mins on my calendar for a Zoom (9-5). Shoot me a DM on Twitter (@MattLovesMath) or LinkedIn if you'd like to.
I would encourage you to rethink this idea.
My advice: - There is no defined learning path yet (to my knowledge). - Start by reading the GitHub readme of technology in these articles (ex: nginx or kubernetes). - If interested, try to spin up a tutorial app. - Try to make something useful. Maybe this is a spin on a tutorial, or something novel. This is the hardest but best way to learn.
Finally, I’ll add that many folks learn these skills on the job either directly or having worked in proximity to new tech. It does seem this was how the author learned.
Hope that helps! I’m sure others will have great advice, too!