I highly recommend switching to something more like Arq and then using whatever backend storage that you want. There are probably some other open source ways to do it, etc, but Arq scratches the itch of having control over your backups and putting them where you want with a GUI to easily configure/keep track of what is going on.
Maybe there's something newer/better now (and I bought lifetime licenses of it long ago), but it works for me.
That said, I use Arq + Backblaze storage and I think my monthly bill is very low, like under $5. Though I haven't backed-up much media there yet, but I do have control over what is being backed-up.
I have used Arq for years. It has always been the least problematic, least intrusive, most reliable backup and restore option for me. Appreciative to Stefan Reitshamer for creating and maintaining it.
Arq saved me a few hours of work recently when VS Code's GitHub Copilot looped out on a Playwright screenshot (>8k pixel height) and I had to manually edit the JSONL chat history, but accidentally restored to the previous checkpoint. That was one time I really appreciated that I set Arq to back up hourly. (I only restore from Arq maybe 2-3 times a year.)
If you are a stickler about automation, easily repeatable system state, and being able to bootstrap new projects without having to eff around with the crap show of Ruby/Python/Node envs and how every person likes to use different tools for setting those up, or even just making it simple to have repeatable envs for go and rust, its great. Especially because you can do it without getting Docker/containerd involved.
Works great for getting a basic repeatable CI type build up and running without having to get CI or a big build system involved. Those are the right tools in the right situations, but for small teams or personal projects, I'm not going through the hassle and JVM dependencies of Bazel, Gradle, etc.
I also use it to manage my local system tools in my dotfiles (in combination with chezmoi).
>having to eff around with the crap show of Ruby/Python/Node envs and how every person likes to use different tools for setting those up
This was the problem I wanted to solve, and I ended up on nix+direnv (and am considering devenv) because nix, due to the existence of nixos, packages all the tools already! Does Mise support zig? or nim? or crystal? Nix does! And Nix will continue to keep up to date with all the tools, whereas things like asdf and mise - since they're specialized and not the basis of a full distro - are less likely to do so.
If you think of it more of in the context of making it easy for people other than you and your bespoke machine to bootstrap a project, that's where it really shines. The toml config is very simple for people to understand.
I use it because I want people to be able to get projects up and running quickly without having to comb through an outdated README, trying to deal with all of the different ways people like to install and use non-compiled languages, etc. Managing anything Node/Ruby/Python is all annoying.
Taskfile is so much better. mise is what actually got me to start switching everything to Taskfile instead of Makefile as mise easily handles bootstrapping Taskfile and anything else you would need.
Had been using make for simple tasks for ~8 years and just got tired of how limiting it is.
I have been a Software Engineer in the field for around 18 years and have worked at numerous companies.. I've been employee #1, and have also worked at a company with around 100K employees across the globe.
I haven't yet been a founder, but I've been at 3 startups which have been acquired. At this stage in my career, if compensation is your primary concern, my opinion and experience is that your best bet is a bigger company who offers stock as part of your compensation somehow. I've definitely made more at a bigger companies than I have as an employee of successful startups with liquidation events.
However, when I was younger, startups were a great place to get interesting experience and network with some great people. I'd recommend working at them if you are in your twenties, or founding one if you have the right personality and backup plans for that. I'm in my mid 30's and would be relatively hesitant to be an employee of startup in its early days now.
You also need to consider if it's a true startup, or just a smaller mom and pop lifestyle type company which is not growing like crazy. The latter is probably better for someone like me, but a quality startup in your 20's is something you'll look back on fondly no matter how much it may have sucked at the time. It's a roller coaster ride but you'll get great experience and have a great network of people to know when you get older.
Keep in mind I'm speaking as an employee-- a founder of a startup is a totally different thing.
In my experience, bad advice (though I agree it may work for some).
I made the mistake of joining startups early in my career. I still suffer because of those decisions. It is much better to work for a big brand when you are young. Yes, in startups you get to wear a lot of hats but unless you are really lucky, you never learn anything in depth. Big companies have enough good people to learn from if you are motivated enough (as I was). And worst of all, unless you are one of the founders, and the startup is reasonably successful - then they will bring a "VP of Engineering" from a big company after two years irrespective of how much you have helped them build their systems and probably deserve that role.
I guess my startup experiences were different. In one startup I worked at, I learned A LOT about data, databases, JDBC, connection pooling, JVM tuning, etc, because the volumes of data and we were working with were just unheard of at the time and the traffic to that data was not cacheable. I had to disassemble a vendors JDBC driver and tell them why it crashed all the time for instance.
In another, it was lots of JVM knowledge (both threading and memory management/garbage collection), caching, distributing work which needed to be calculated, etc. We found several JVM thread locking bugs and worked with Sun to fix them. I worked with some really great people in their 40's at this one and learned a lot from them.
I suppose the majority of startups are different these days though? Mostly RoR and Node based social things. The biggest worry is if the Facebook Like and Share buttons work.
If you are working somewhere that is only a CRUD website at it's core and doesn't have anything else going on, I suppose there isn't much to learn on the backend side of things.
I think the sweet spot for a brand new developer is a company with about 50 people. That way there are other, more experienced developers you can learn from and yet there aren't so many people you're doing someone else's job when you step out of the very narrow confines of your own.
Some of the people from my graduating class in college started at really large companies and learned nothing because they were such a small cog in a really large machine. I went to a company which varied between 40 and 50 people and had the opportunity to learn as much as I could soak in.
Anyway going to a startup is a lot like gambling. You'll most likely be looking for another job soon, but if it pays off it may pay off really big. Who cares if they bring in a "VP of Engineering" if I can cash out my options for six figures?
If it's been two years, the options are worthless, and it looks like you're going to end up a low level employee at a larger company, then it's probably time to move on.
Truth is, YMMV. I have only worked at startups and smaller companies (& a mid-sized non-profit for my first job), and I mentor my junior developers quite frequently on improving code quality & code design. They also get the space to work on features & sink or swim based on their decisions so the lessons hit harder - the responsibilities are great, and they aren't just siloed into maintaining existing code. They also get to see the difference between excellent code & code that they have written.
It is hard to speak for all startups since they're a dime in a dozen.
My hypothesis is that working in small companies (or startups) like Fog Creek where the goal of the founder is to be sort of "be happy and make some money at the same time" is going to be a far better experience than the typical company whose goal is "Let's acquire users so that there is potential to display ads which means that I get funding or get acquired". Of course I have no data to back that up.
But aren't the big companies often very slow and boring to work in? Of course they have some interesting projects but if you really want to build something from the ground and work together where the whole company is in the same team it will hard to achive in a big one
The sweet spot is to find a company developing a new product or something of the sort.
Where I work now I started on a new product that was young, and since moving on from that project, we have replaced many legacy applications/products. I've done my longest employment stint (4 years) of my career because it's been my best job at this point.
Similar boat. I've found work quality wise it also comes down largely to the people. A traditional new-product "startup" has a lot more potential for a monomaniac egotistical founder that interferes in everything you do, appreciates nothing, and makes things miserable, far more personally so than the "big corp beaurocracy" people complain about (and yet still pay less than them). Big corp you can usually at least transfer departments / managers if things get too out of sorts. For me the best fit has been the small consulting agency; diverse projects with lots of flexibility, and stable enough to recognize the value of good employees and usually give decent raises and benefits.
Maybe there's something newer/better now (and I bought lifetime licenses of it long ago), but it works for me.
That said, I use Arq + Backblaze storage and I think my monthly bill is very low, like under $5. Though I haven't backed-up much media there yet, but I do have control over what is being backed-up.
reply