I agree with the team-size aspect, but the age argument won't always hold.
Junior folks bring their own energy, flexibility, hunger for learning and the resilience to unclear future. As folks get more mature, growing egos, stability expectations, tendency to settle down can get in the way.
Overall, this boils down to the fact that teams and people are not just head counts and there's a factor of chemistry need to be considered depending on the culture, founders, geography and the business itself.
... arrogance, hunger for prestige and one-upmanship which leads to fixation on irrelevant outcomes, laziness in learning "old things", and rejection of instructions.
Thanks for creating this content, this looks pretty good and it was a good time for me to refresh my basics about computer networks.
I tried checking the content with my kindle (a Kindle Touch paperwhite 6 inches) and the first chapter rendered pretty good, with images and text aligning as intended. However the second chapter did not render the first figure and beyond. Chapter 3 rendered OK, similar to Ch 1.
A few more feedback if that helps for enhancing the format even more:
- Colors, and references to those do not work on a kindle. I only saw one minor use of colors (red, green) in Chapter 1 so that's not a blocker.
- For some reason, the kindle browser doesn't put left and right margins on the page, so the text uses the full length of the device.
- Links are rendered with a pale gray, sometimes hard to distinguish.
- Figuring out why the Chapter 2 did not render would definitely help.
Workflowy, alongside a regular email and calendar. Workflowy is very simple yet flexible and has the tools that make me operate without thinking much.
It allows me to quickly keep a GTD-ish list of stuff going on and action items needs to be taken and I can organize them as detailed as needed with labels, colors, etc. I find the simplicity/features ratio work well for me.
This is a good thing to think about if you want to make something a habit, or you simply wanna do it more often. I picked up some hobbies that I hadn't been doing very often since I started working by writing some glue code and setting up some programs so that when I want to do the thing, everything's already set up for me to start, and I don't have to dedicate any mental capacity to searching for the things I need and so on.
For an example more related to programming: in my last gig at work I had to develop some react components for this massive project, and there was a folder containing hundreds of components that had to have a specific file structure (one file for the component, one for the tests, one for the types, one for the SCSS styles, one for the storybook), so to create a new component there was a lot of boilerplate you had to write every time.
You could see that this was influencing the internal design of the components: people tended to prefer writing massive components that handled lots of state and displayed lots of things at once instead of breaking everything up into smaller, more manageable components.
Just writing a script that set up all that boilerplate automatically improved both the workflow of the developers and the design of the code, because people were more likely to create a smaller separate component when working on a feature rather than lumping everything into one monolithic component.
These stories are everywhere. A couple months ago, it hit an associate of mine pretty hard, he moved a small python monitoring and statistics application off a laptop in the office to AWS. A couple weeks later he came back and discovered that it had burned up a few thousand $'s in storage and transfer fees for what normally was a couple hundred MBs of data a day being passed around and a some database updates.
Since it wasn't really worth debugging what went "wrong" it got chalked up as a learning experience and moved back to the laptop where its happily running. If it dies/whatever its no big deal, just a git clone;./runme; and it rebuilds the whole database and creates another web facing interface.
The IaaS guys are masters of marketing. They have convinced everyone that their offerings are less expensive and more reliable, which repeatedly is proven to be false in all but the most dynamic of situations. In this cases its saving $7.99 a month over a unlimited site shared hosting godaddy/whatever plan. Just in case it might need to scale a lot, in which case your going to be paying hundreds if not thousands in surge pricing.
Not sure what happened to your associate but this sounds way, way out there. I run a fairly resource intensive SaaS on AWS (lots of background jobs generating data) and we barely go over $600 a month.
People should not be scared of by these anecdotes, however true they may be. It’s perfectly possible to run a very cost effective business on AWS.
Starting to think the reason we arnt working for google/aws is we make mistakes. Whereas engineers at those companies just dont make mistakes, therefor they assume that billing caps are not necessary. Such is our lot in life.
I think the bigger difference (other than a potential skill difference) is rather that they're more willing to take these risks. The ones that are good at it and succeed will rise to the top!
Bug free is a not realistic but if you are a programmer and definitely if you are a tech founder you definitely should be willing to bet your financial future on writing reasonably low bug code.
If you are a programmer, I kind of find the comment puzzling; maybe I am reading you wrong, but you seem to be saying that you are writing code for some company while being happy to commit it and not care if the company loses money if your code is bad? As you would not bet on your work yourself, but you do not mind your employer paying you for it and as such betting some of it’s financial future on your work? Sorry if I misunderstood your comment.
When you work for somebody else (or with somebody else) then you try to do as good of a job as possible, but the ultimate responsibility still lies elsewhere - might be your boss or could even be the group. There will be other people who interact with your code and might spot errors. There will be people who are trained, in some capacity, to figure out ways to mitigate against accidentally generating very large bills. It is exceedingly unlikely that these points hold true for a solo developer working on a main project, let alone a side project.
Even if you are hyper competent and can probably get all of this correctly, you can't rest easy. You simply don't know whether you did everything correctly or not. Just one dumb mistake can saddle you with an enormous bill.
This is just like gun safety: don't point your gun at anything you're not intending to shoot. Mistakes happen and the consequences of it can be catastrophic.
You are right, but at some level you are thinking 'you can do it' right? Otherwise you would be pretty miserable I would imagine. But I agree with the rest you wrote. You meant it slightly more nuanced than I read it!
You are absolutely right; no idea (thinking hard what service I was thinking off now) why I typed that. I was thinking of something entirely else. No-one try this; bad advise; they will indeed come after you. Not
AFAIK, PaaS solutions like heroku have a similar way of working, at least for side-projects. Here, you deploy a container and Google runs it somewhere and Heroku containerizes your application every time you push it. Similar to here, Heroku's free hobby containers also go to sleep in ~30min inactivity.
