pfitzsimmons's comments

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')

Voila! That's all the code I need, and it works great. I can easily swap in memcached or a file cache or a local memory cache or whatever. It is straightforward and easy to debug. If I am wondering why the wrong implementation service is being used, I can usually step through with a debugger right at the point it is being called and figure out what is going on. If you I am writing tests, I either use different settings or monkey patch the static class in my setup and tear down functions.

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)