Back Pain, and attempt treatment.

I have been hurting for back pain for now more than 12 months.

My symptoms are pretty common: * Lower back pain (mostly on the right side) * tingling on throughout the legs (that doesn’t happen all the time) * Not extra painful (may be a 6 out of 10 at worst, 3 out of 10 on average), but pretty annoying

The pain came on an off for the past 12 months. Mostly feeling better when I don’t spend too much time standing, or when I swim a lot. And feeling bad after the kind of exercise that requires bending forward or on the sides (Squash).

I know I have a bulging disc (did an MRI). It’s not too bad, but I don’t want that to impact my life. I’m 30.

My guess is that if I have strong core, and flexible hamstrings I’ll be fine. So here is my plan:

  • Swim 2 times a week.
  • Core work everyday.
  • Yoga once a week.
  • Standup desk as much as I can (depending on riding).
  • Ride 100 miles/week

I’m going to track workouts and results on a daily basis in a spreadsheet that I might share or not. will see.

What are the cons and pros of using a hosted MongoDB hosting and running it on Your own VM?

Answer by Mehdi Ait Oufkir:

Your job is to quickly build a product that people use, so you can measure and learn if you should pivot or persevere.

Here is what my guts tells me: you need to focus your brain power on bringing value to your customer. You need to focus on building software, not on Dev/Ops or SysAdmin stuff.

Here is a more objective take on it:
2 scenarii:
1. Your product is not taking off. You don’t have a lot of traction.
    * If you use a DB-as-a-service:
        * The price of hosting will be low (<$40/month)
        * You will have an extra 2-4h/week to focus on iterating on your product to make it successful (and you will probably need it)
        * You will have the piece of mind of knowing experts are watching your DB.
    * If you do it yourself
        * The price of hosting will probably be at least $10/month. (I’m just guessing here, I haven’t done the math)
        * You will have to do SysAdmin, Dev/Ops and DBA tasks (setting up the VM, installing everything, updating the software when it needs to be updated, restarting the box when it needs to be bounced)

2. Your product is taking off. You have traction.
    * If you use a DB-as-a-service:
        * The price of hosting will be proportional to your traction.
        * You can focus on : (1) making your product even better, (2) find a way to cover your cost if you want to stay independent, (3) spend time trying to raise money if you have bigger plan.
    * If you do it yourself
        * You will have to invest ahead of your traction, on VM/hardware.
        * You won’t have time to do the SysAdmin, Dev/Ops and DBA tasks yourself, so you will have to hire someone at typically ($150/hour). This person will not help you build a better product. It will just be an ongoing maintenance cost.
View Answer on Quora

The Reactive Company

The concept of reactive company is something that I expressed while brainstorming after a pretty embarassing bug we found in our platform in the early days at PunchTab. It is a pretty trivial, but really important concept.

To be honest, I’m not even sure what was the bug we ran into. I remember it was pretty embarassing. I remember it affected our customers for a noticeable amount of time. While discussing how we could avoid this kind of issue in the future, I concluded that there was no way to make sure these kind of bugs would not happen if we wanted to stay nimble. The only variable that could be optimized without hurting the company’s agility was the amount of time it took us to identify and fix the issue. That’s when I explicitly declared we needed to be more reactive. Here was our plan:

  1. All trackable business metrics would be shown real-time in a dashboard (We use geckoboard for this) on a giant screen in the office. By using the “in-your-face” method, you make sure that there is always someone in the company that is briefly glancing at the dashboard. And I trained everyone to mention something if a trend looks out of the ordonary.
  2. A good portion of our key metrics have paging setup (SMS, phone calls and emails). We use PagerDuty for this. We set it up for business metrics as well. It does not only track uptime. It tracks activity and engagement of our users. PagerDuty is setup to go off if it reaches certain treshold, which is usually calculated based on the standard deviation of the average.
  3. Obviously our uptime and response time is also setup with tracking, and paging. This is done simply with and allows us to have a objective view of the performance of our system.
  4. If one end-user complains about something, we automatically assume it means that thousands are running into that issue (This works better if you are running at scale). This is probably the hardest to turn into actions in real life, but your answer cannot be “I can’t reproduce the issue”, if someone is running into it, then a lot more are, and you need to act on it.

The goal with this setup is to make sure that when something goes wrong with the system (which happens really often), we are able to detect the malfunction really quickly, and respond to it in no time. There is no waiting 24hours, until enough people complain to start looking into it. I’m actually extremely surprise how little false positive occured in the past 2 years.

This simple rule got us in a place where we have been able to react to crisis before they even existed. And it grew into the culture of the company which allowed us to apply these same tactics for other stacks than product development. I believe this is now stored in the DNA of company, and this how company with a small team can execute so well on so many levels.

Software engineering at startup is not craft

Unlike a lot of the technical co-founder of startups, I did not grow up “hacking” for pleasure. I discovered software engineering much later when I had to pick a major in college. I was lucky enough to pick something I ended up liking, I picked software engineering, which allowed me to learn how to build stuff that people used; that’s how I like to call it. The emphasis on the “people used” part is actually important. I did not necerarly like building software for the sake of building software. I actually enjoyed the vision of the software being used by people. I think that’s why I was so lucky to end up in the startup world, even though I was train for a broader “Software engineering” industry.

I could only see my way in this industry if I could build stuff that would be used, by a lot of people. It did not need the sofltware I built to change people’s life, or the world, I just needed it to be used.

After college, I ended up being lucky enough to intern for, which was a typical fast growing startup in the Silicon Valley. I knew almost nothing, but as soon as I got my buggy software into people’s hand, something happened to me, and I really strived getting better at building software. Not getting better, for the sake of crafting beautifully engineered software, but getting better at delivering web applications that would be used by millions of people.

When a startup launches, the only focus that the product development team should have is how to get as many people as possible to use the application.

The type of engineers that makes a product development team succesful in the early days of a startup, is not an engineer who builds software as a craft. It is not an engineer who focuses on creating the most elegant software architecture. It is not an engineer who wants to use the latest technology, nor the best-most-obscure algorithm. The type of engineers that makes a product development team succesful is the type that strives to ship software to get people to use it. His self-proclaimed success should correlate with the number of people who use the product he builds, and its growth.

Comes a time engineers need to use their craftmanship to build software, but it comes way later in the life of the company, when shipping codes involves enough engineers that non-crafted code could affect how the product is being used. As engineers we all have to keep in mind the reason why we are building software: for customers.

A number of the responses brought up Firefox. As in, Chrome seems to be heading down the same path that Mozilla’s web browser went down a few years ago. What started as a fresh, fast answer to Microsoft’s Internet Explorer at the height of its dominance, eventually became a slow, buggy, bloated turd.

Dear Chrome, Slow Your Roll | massive greatness by MG Siegler

That’s why Safari is till the best browser around. period.


Just a reminder.

Yep. I&#8217;m buying one today


Just a reminder.

Yep. I’m buying one today