pfitzsimmons

I remember flipping through the Sear's Wish Book as child, coveting all the toys. You can still find old copies online: https://christmas.musetechnical.com/

What's actually happening is that China's manufacturing revolution has given us incredible access to cheap manufactured goods. So for instance, in the 1991 Sear's catalog an electric toothbrush costs $80 ( https://christmas.musetechnical.com/ShowCatalogPage/1991%20S... ). There are only brand name options. In terms of prevailing wages, that is about $200 in today's dollar. Now on Amazon you can get that same brand name toothbrush for $50, one quarter the price, or a nonsense-brand-name one for $10, 1/20th the price! One man's race-to-the-bottom is another's man paradise of inexpensive and abundant goods...

When China started making stuff so cheap, nobody wanted to buy a much more expensive brand-name Japanese or American or European made product. So even the brand names decided to move their production to China. But then gradually people learn there is no longer any brand name quality boost, and the Chinese manufacturers learn to sell direct to consumers, and so then you get the all the weird brand names, and consumers just buy those for cheaper since the brand names don't mean anything anymore anyways. And even if you wanted to introduce a higher quality version, there simply is no way to reliably educate the consumer and credibly prove to the consumer that your product is four times the durability at twice the price.

Thus the equilibrium is that for most products less than $100 its all going to be Chinese made, the product will be good enough that the consumer won't immediately return it, but other than that the quality is going to be mediocre, because there is no incentive to develop a brand name that stands for high quality products in that price range.

With more expensive goods, there are still are brands that pride themselves on high quality, durable products, eg, Toyota for cars, Bosch for appliances, Milwaukee for tools, Redwing for boots. But you have to do your research to know which brands are working to keep their reputation, and which brands are selling out.

That's not a big deal for me since I only am running a handful of servers. I install it system-wide during initial setup of a new server. Plumbum has the ability to run remote shell commands as well, so I have a script that can login to a new remote machine and do that initial setup.

As a pythonista, I am a huge fan of the plumbum library as a replacement for bash. It makes it very straightforward to run a sequence of *nix commands, but you get all the simplicity and power of the python language in terms of loops and functions and so forth. These days, I do all my server management and deployment scripts with python/plumbum.

And while simple is great, the necessary features not included in OP's scripts is that I want to spin up the new instance in parallel, verify it is running correctly, and then switch nginx or the load balancer to point to the new server. You are less prone to break production and you get zero downtime deploys.

I switched from Riot to Vue, and am glad I made the change.

Biggest things I noticed:

1) Getting stared with the basics is about equally easy in both frameworks. Both have a very simple and clean API and component system.

2) Vue has more advanced features -- dynamic components, easy two-way binding, watching variables, custom events, routing, etc, all of which I have used at some point as my app has gotten bigger

3) Riot seems to have more open bugs, including one major issue where even when an "if" statement evaluates as false in a template, the component still gets processed. This is supposed to be fixed in the next big release, but who knows when that will be.

4) Vue seems to be much more active -- more users, more commits, so I think it is a better long term bet.

I worked at HubSpot for many years. (disclaimer - I do not have a financial interest in the company. But I do still have strong emotional and social connections, and I was there long enough that I feel some sense of ownership for the company culture).

Remember that this article is written in order to entertain and sell books. Everything is hyper exaggerated. There are a few fair points (for instance we were very overcrowded, we could not lease new sections of the building we were in fast enough. And yeah, some of the "change the world through Inbound marketing" messaging was over-the-top and made my eyes roll). But a lot of it is either inaccurate or spun to seem bad when it wasn't (see my other comments https://news.ycombinator.com/item?id=11370077 or https://news.ycombinator.com/item?id=11370016).

For the most part, HubSpot was a normal workplace where the vast majority of the time people worked hard and did their thing. People occasionally interrupted work for fun hijinks and we did sometimes have parties after work. By packing in every outrageous story into a few paragraphs, he makes it sound way crazier than it was.

I should also add that overall work-life balance was pretty good, and the company made efforts not to be "ageist". I had both mothers and fathers on my team and they could get out of the office on time to be with their families. As we matured, we planned our fun team-building events in ways to ensure that parents could attend them. There is an implication by the author that he did not fit in because he was old, but I do not think that is a fair critique.

I worked there, it wasn't anything as bad as what he makes it out to be. It was just shorthand for saying, "the whole is greater than the sum of the parts."

Our whole sales pitch was that we were all-in-one software. So instead of running one system for your blog, another system for your home page, another system for email, another system for analytics, another system for your contacts database, etc, etc, you would just run HubSpot, and when all the tools work together you get much better results then when they are separated. To make good on that sales pitch, we had to be constantly thinking of ways of how we could add value by integrating pieces together and making things work well together. Hence we were told to always be thinking about how to make 1 + 1 equal 3.

I worked at HubSpot in engineering and I never once heard the term "graduation" in reference to a firing. Usually we just got an email saying, "HubSpot and John have decided to go separate ways" or something to that effect. If someone left by their own choice, usually they would send a "this is my last week" email and we would all go for beers on the last day. The term "graduation" was rarely used in either case. I only remember it being used in the context where an executive would say something like, "John did great work for us, he's now going to be a VP at a new startup, we want to think of this as a graduation."

1. There was a history of heavy-weight, overly verbose frameworks. The early frameworks were over-engineered and hard to use. Lightweight frameworks in dynamic languages (Rails, django) thus took off when you they showed how you could write a blog app in fifteen minutes using only a few dozen lines of code.

2. Using non-Java JVM languages seems to always create as many problems as it solves, in my experience. First, you do not get access to any libraries with C-bindings. So as your project gets going, the probability increases that some library you want to include won't work. Also, there are all sorts of micro-frictions. Debugging support not quite working. Types not matching between Java numbers and python numbers when doing comparisons. Etc. It all adds up. If you use Kotlin, then a lot of code samples you find on stackoverflow will have to be manually converted.

3. If you go pure Java, the type system can be a pain in the neck when you are doing rapid development. Something as simple as getting a row out of the database with date field, publishing it as JSON, then getting posted back an updated version from JSON, requires a bunch of conversions and annotations to make the types all get matched correctly. Writing any sort of time-saving meta code requires a really strong knowledge of how generics, annotations, and reflection works, or else you will be beating your head against the wall.

4. Restart times are longer, and there is no REPL, so rapid iteration is a little slower.

5. I still don't think there is a web framework that is as easy to use as Rails/Django. I don't think this is the fault of the language though, and I have something in the works myself on this front...

This looks like this could be a big deal. Kickstarter would be a lot more fair and more compelling if the backers were also investors, and could get a piece of the upside when helping to support development for a risky product. And it makes a lot of sense that consumers should be investors, since they often know the space better than a VC.

My immediate concern is that these rules look somewhat complicated. What will it mean to have to file a modified version of an S-1? How much will compliance cost when trying to go this route? Maybe there will be an enterprising YC company that help with Reg A+ compliance automation...?

I went through this exact situation. I joined a company when it was just the founders and me, and then we grew to dozens and then hundreds of people. As we grew, I felt these same slights: I was left out of strategy meetings, I was not mentioned on the website, managers were hired over me, etc. Overall, it felt disconcerting as more and more happened outside of my control, and without my knowledge. At first I was frustrated, then I realized I had the best of all possible situations.

Some notes:

1) If you do not have much experience scaling a team, then it is sensible for the founders to bring in someone with more experience. Scaling team requires more than just hitting deadlines. It is about recruiting, retention, recruiting, managing personalities, career growth, recruiting, managing up, communicating across teams, etc.

2) Everyone's role changes as you grow, for better and worse. For instance, early on the VP gets to have fun setting direction and designing the overall product and strategy. Later on the VP might be spending 90% of their time dealing with conflicts, recruiting, firing, managing up, etc. They may long for the day when they got to play a big role in product development. Early on as engineer, I had the benefit of being able to build an entire product by myself. Later on, the advantage was that I could take vacations and did not have to deal with bugs and outages 24/7.

3) You will have to specialize to some extent. You cannot be the jack-of-all trades role forever, no one can. If you want to eventually have a VP/CTO role, then you will need work with your VP to develop your management abilities. For instance: ask for mentoring, start reading books and articles on management, ask to have a junior engineer put in you, help out with interviews and recruiting. (Note to actually get a VP role, you will probably have to switch to a smaller startup in a few years, using your cred from this gig to get you the job.) If you want to do greenfield development, work with your VP or founder to carve out a role building out innovative/experimental/skunkworks features. If you want to do scaling and architecture do that. There are lots of ways to interesting work and build valuable skills, but you are going to have to choose a course. (In my situation, I alternated between doing experimental/greenfield features and doing scaling/rewrite work on existing tools.)

4) With regards to customer facing roles, I highly advise that your company have a policy that every engineer spend a half-day in support at least once a month. It is essential that developers stay connected to the customer, both so that you can intuitively understand how to solve their problems, and to increase your empathy and motivation.

5) Try to figure out a way to get looped-in informally to the strategic aspects of the business. Make some sort of effort to have lunch or beers with a founder once a quarter. If you have 1:1's or have a wiki where decisions are discussed, then that can be a good thing. The execs understandably want to keep management and strategy meetings to a small number of people, otherwise the meetings suck. But finding a way for you to informally connect and give your two cents can be valuable both for you and the execs.

6) If you want to raise your profile and get your name known, use whatever leverage you have to get some favors. Ask to have yourself put on the web site as "Founding Engineer." Figure out a way to have the founders to introduce you to useful people, and to help you get into some of the more prestigious invite only events, whatever they are in your area. You have to use judgement and be diplomatic, because you might also lose out on advancement if you are seen as angling for a quick exit.

7) Generally, I would recommend sticking with the company as long as it is on an upward trajectory (unless you have a compelling alternative). You will learn a lot as you go, and your reputation will increase with growth.

Eventually I realized that I had the best of all worlds. Why does one want to be a VP? Usually money and status. What sucks most about being a line-level employee? Lack of agency/control. But in many ways it is less fun to be a VP, than to be a high-status engineer, who has enough sway to avoid micromanagement, enough credibility to control his or her own destiny, who can spend their time working the craft that they love. As engineer #2, you get status by virtue of your early employee number, and hopefully and you will get good money from equity stake (if not, then that is truly unfortunate). So hopefully you get the money/status benefits of being an executive, while still getting to work your craft, and still getting to stay in a peer relationship with your fellow engineers.

"For any significant piece of logic, it ends up living in a class on its own, with its dependencies injected either via constructor parameters or method parameters."

And I was worried I was the only one who thought this was crazy!

In most python frameworks, like django, when you want to call some service, you import some static class or singleton. It is simple and straightforward. If the framework wants to allow you to swap in different implementation classes, then it will define a singleton or static class with a clear API that then dispatches to the specific implementation class based on your global settings. Or, if you want to override the default implementation on the spot, you can just invoke the implementation class you want directly.

So in django, I just do:

  from django.core.cache import cache
  cache.get('my_key')

In most java frameworks, your classes are supposed to either accept the service via a constructor, or have it injected into your class via Guice or Spring. This adds a whole new level of complication and verbosity, and means things break far away from when you are using them. I know people swear by dependency injection, but I really don't get it, I have never found it to be a better pattern than the django pattern.

Were the paying customers actually using it? Did they love the product (ie, would be a 9 or 10 on an NPS survey)?

If yes, then you should have worked more on sales and marketing.

If no, then you built the wrong feature. Blindly adding a collection of features won't help. You need to figure out what the one feature is that will make customers rave about the product.

The core problem might be that your product ideas were "pretty good" ideas and not "very good" ideas. "Pretty good" ideas are deadly, because they are just good enough to suck you in, but not good enough to make a product that customers rave about, and thus not good enough to make with a product that is easy to market or spread by word of mouth.

Gestures are much less efficient than using a mouse or touchscreen, gestures require more muscles and movement and are less precise. Voice commands beyond the very simple stuff is an AI complete problem. True AI is much further away than we think. And when it comes it will be so deeply weird and also mind-blowing that asking it to buy us plane tickets via voice command or whatever will be the last thing that we would be worried about.

If you look at the biomechanics, it does seem like a keyboard + mouse + >=20" screen is the optimal setup for doing actual work. A keyboard is simply the most efficient way to get information into a computer (the exception is that some graphics editors work might work better with a multitouch screen, it will be interesting to see if someone builds a touch-first photoshop killer). That said, there might be a convergence where mobile devices learn to run desktop software, and can be docked to a mouse/keyboard/monitor. But we are still a long ways from that point, and there is no great incentive to build office suites for mobile devices that are efficient for power/work users.

Mobile is great for 1) consuming content 2) interacting with your extended environment when you are not grounded to a computer (summoning an Uber, paying with an app, etc.) The money in content consumption will go to either the content creators or the digital sharecroppers (Facebook).

So the question is, are there large untapped areas where a phone could be used to interact with ones environment? What kind of day-to-day things could be enhanced with internet connected software?

My favorite term for it is "Eye of Sauron" management. Most of the time the eye is not on you ... but when it is, look out!

The point of a microservice based architecture is to allow a large team (15+ people) to work together without stepping on each others toes. The idea is you break the application into smaller services, and each service can be iterated on and deployed by a small group of 1 to 4 people. I cannot see any reason why it would be a good idea to adopt a microservice architecture for personal projects or for a startup with less than 10 people.

I did work on an application suite that included a blogging platform, that aimed for a service based architecture. We had services for: * taking screenshots of the rendered blog post, for use in preview thumbnails * user identity and settings (shared service for the entire suite) * asynchronous task handling * sending emails * adding blog post analytics to the dashboard * all things commenting (including a javascript embed code) * the main application for editing and rendering the blog content * customizing blocks of content based on visitor identity

This is great. You should have an offer a combined zip file with all the mp3's as a $5 download. I would pay for it.

So 2,200 signups turned into 9 active users. If those were paying customers, than that is a .5% lead to customer ratio. There are companies that have built large businesses with a ratio like that. I'm not saying that OP should continue the business, his other reasons for giving it up may be valid. But a .5% conversion ratio is really not that bad for a brand new product. Very few products are instant hits.

I would love for someone to start a company that could bring fiber to cities via the kickstarter model. Getting the money upfront from customers could go a long way toward mitigating the risk. Ideally the company would be structured as a hybrid for-profit/customer co-operative (so maybe 20% of the shares would be 10X preferred stock owned by the for-profit arm, and the other 80% of shares would be owned by the customers).

It is more precise than normal English dialect, but still much less precise than math or python. At root, the phenomena that legalese describes are often imprecise. For instance, there is no perfectly precise way to describe the boundaries of a non-compete agreement, or what exactly constitutes "negligence." (This is why we cannot actually replace law with code)

Math, English, Python, Chinese, Ruby - these are all just languages. Programming languages and Math are simply languages designed to be good at describing phenomena that can be defined with precision. Programming languages are optimized for describing precise sequences and procedures, while the language of Math is optimized for describing precise proofs. You could actually write pretty much anything that is written in math or Python in English, but the English language has so much ambiguity that you would be more prone to making mistakes. English would also be much more verbose and would not be parseable by a computer.

"He wants the rest of the people to first hear: "We're changing for the better, and while these layoffs are a bad thing, it's necessary pain we have to go through to be better in the long run."

Right, but the question remains, why did he not just say exactly what you just said? Why use the business school/managementese style language? Why not use language that is human and expresses empathy?

One approach is to start documenting how much of your time is spent either a) manually testing changes because you have no automated tests b) debugging, fixing bugs, and patching messed up data due to bugs that easily could have been caught by tests. I find that investing in basic acceptance tests pays itself off very quickly. Good tests allow you to iterate on your early product much faster, because you can actually make changes without breaking things for your early users. If you can document the wasted time, maybe you can convince him of the benefit.

"My intuition would be that functional startups are visibly functional; they feel awesome."

It is a lot more complicated than that. The term "sausage factory" usually applies - http://www.urbandictionary.com/define.php?term=sausage%20fac.... Even very successful startups can feel very dysfunctional in the heat of the moment. First, when you grow fast and do things that have never been done before, lots of things break. Second, very often management may be absolutely brilliant about some matters, but have giant gaping holes in other areas. A CTO may have figured out a breakthrough in machine learning, but have no idea how to run an engineering organization. A CEO may be able to sell sand to a Sheik, but have no idea how to do proper accounting. As a company matures, it figures out a way to augment the leadership and compensate for weaknesses of the CEO or founder. But there are always growing pains early on, as a startup has not yet identified and fixed said holes.

You really should be evaluating a startup by the high notes that it is hitting, not by the amount of dysfunction. So it should feel awesome at least some of the time. But the startup may very well feel dysfunctional most of the time. That is ok, the dysfunction can be fixed later, but if there is no market or technical breakthrough, then the startup is probably not going to do well.

OP, the questions to consider are: do you have a product that people love (ie, they use all the time and recommend it to others)? If yes, is this a sample of people that is representative a bigger market opportunity? Does your CTO seem reasonable enough that if you demonstrate the value of tests and a build process, he'll allow you to allot time to fix things?

For a B2B product - identify five people to whom you can honestly say: "You would be stupid not to buy this product" These should be real people you can name - not hypothetical people. If you cannot identify such people, but think they are out there, do everything possible to find them. Go through Linkedin and see who in your extended network fits your target market and find someway to talk to them. Email people or message people on blogs or social sites that seem to have the pain point you have identified. In reality, you will need to talk to far more than five people in order to narrow it down to five people who clearly need your product.

Once you have found a set of people who need your product, get their feedback on the idea, show a mockup or prototype, and ask if they would buy it. If a bunch of people say "yes", time to go build! But as you build, make sure you check in very regularly with potential customers, so that you stay on a the right track.

Keep in mind there is a big trap you must avoid in this process. Many prospective customers will be positive about an idea, but they overestimate their own willingness to get through the friction involved in adopting a new product. So the prospect says the idea is good - but then you build it, and they don't actually use it, because turns out email and excel had a bunch of hidden benefits that make them better than your product.

As an entrepreneur, you need to implore people to be brutally honest in their feedback, lest you build the wrong thing. You should focus more on identifying their pain-points than on pitching your own solution. You also have to make your own judgements about how big the pain point is, rather than just blindly trusting a prospect when they say they would buy your product. And you should to some extent reverse pitch - ("Did you think of solving your problem by doing X? Do you really need me to build a product to help fix this?")

Two of the biggest factors in our happiness are a) the quality of your job b) the duration/stress of your commute. America faces a shortage of plots of residential real estate that are within a reasonable commute of quality of jobs. And you need to be in commuting distance of an abundance of good jobs, because job conditions at any one company can change fast, leaving you stuck. Suburban sprawl worked for a while, but in many metros the cheap land is so far out that the commuting times are horrendous.

Why don't you use QuickBase or Zoho creator? ( http://quickbase.intuit.com/ or https://www.zoho.com/creator/ )

Thanks for the reply!

Out of curiosity, why did you leave Softlayer for EC2? I am looking at hosting for a new venture. Past experience with EC2 pricing and performance has left me feeling a bit burned, so SoftLayer is among the options I am looking at.

Funny enough a friend of a friend of mine actually wrote a book with a very similar theme - "Three Parts Dead" by Max Gladstone ( http://www.amazon.com/Three-Parts-Dead-Max-Gladstone/dp/B00D... ) The book was inspired by the 2008 financial crisis, and features deities who make contracts for uses of their powers.

It's a terrific book, and a very fresh concept. I highly recommend it, especially if you like world building.