When you talk about the point or purpose of open source, what are you referring to? I think of Stallman, print drivers, and users owning their work, so your assertions about the point of open source ring false to me.
I live just west of Lake Michigan, and what you described would be a high-snow winter here. The lake effect is real. I grew up in the Cleveland area, and I was surprised how much less snow we get in Wisconsin. Longer, colder winters, though.
> lurk in the middle of the road and make a left turn once oncoming traffic is stopped for the red
In the jurisdictions I'm familiar with, this is the proper way to make a left-hand turn. Many intersections are designed such that this is the only realistic way to ever turn left (high traffic, no left arrow).
Most red light rules are written against entering the intersection on red. If you're already in the intersection, you're allowed to safely proceed through and out of the intersection on red. That can be challenging, of course, if oncoming traffic is running the red light.
Just to add a counterpoint, I was hired as employee #3 in 2011. In 2020, I was able to sell 5.8% of my stake for $200K (as part of Series C). In 2021, I sold another 4.4% for $500K (Series D on terms too good to refuse). I still hold equity or options in nearly 0.5% of the company (which is still private).
My wife and I used about half the proceeds of those sales to buy a house (cash offer) in late 2021.
I don’t know what proportion of early employees get screwed, but people who do well are usually smart to avoid posting publicly about it (and I am apparently an idiot).
We generally don't have 6-month old branches. We don't shy away from assigning big projects to devs, though. They iteratively collaborate with our Product team to carve out a v1, and then get to work. We throw out reliability on delivery dates of any one feature, believing that we achieve higher throughput with less coordination (we avoid dependencies between features as much as possible).
The assigned dev absolutely breaks the big feature into reasonably atomic pull requests, ideally no more than a few hundred lines but sometimes a few thousand. The critical difference, I think, is that none of that breaking up is super planned out, and it's certainly not formalized prior to development. The changes often trickle out over several releases. Collaborators may help advise on where to break things up, but ultimately it's up to the dev to use good judgement.
I agree that 6 months of unmerged development is absolutely a horrible situation that's best to avoid.
We make basically no attempts to estimate how long a feature is going to take and then update those estimates along the way. An individual feature could take a few days to implement or several months (years even). Periodic check-ins are completely independent of the 4-week release cycle.
Every 4 weeks, we release whatever has been merged in the last 4 weeks. One dev might have 8 independent changes in a release or 0. We typically have a handful of significant changes that land each release and a bunch of minor improvements. Still, there's not much effort to estimate when any particular feature might land.
When a large feature is getting close to completion, the dev might choose to push a little bit to hit a particular release. There's not really any external pressure to do that, though.
I really don't think so. We have processes that happen on a 4-week cadence, and about 10% of the engineering team rotates through duties in shepherding those processes. For all other devs, the experience is to pick up a feature, work on it for as long as it takes with periodic technical check-ins, complete the code review, and then pick up their next feature, completely independently of our 4-week release cycle. Is that still sprints?
Everything I've read to this point seemed to describe sprints as chunking every task so that it takes no more than 1–2 weeks to complete (depending on the company's sprint length). I inferred that a dev would be expected to pick up and complete one of those task chunks each sprint. I have seen occasional references to tasks that last 2 sprints.
I was contrasting with that model, though it sounds like I might not be accurately characterizing sprints. We've had some features that have taken over a year to complete, such as a major rearchitecture. The (generally senior) dev assigned to that task has a lot of latitude to break it up according to their judgement, submit individual parts on their own timeline, etc., all while minimizing bookkeeping and coordination with others. As long as they're continuing to make forward progress according to an initially vague, sensible, iterative plan, we tend to leave our established devs to their own devices. For newer devs and where multiple devs are collaborating on a feature together, we encourage at least weekly check-ins.
Standups (weekly, not daily) worked pretty well for us at 5-20 people: maybe 5-12 devs and 2-8 other stakeholders. Smaller than that, and communication was so easy and natural we didn't need standups. Bigger, and it became tedious and low signal (everyone didn't need to know everything).
We now have more than 50 devs, and we've remained quite flat and autonomous. It would be literally impossible for me to track what all the other devs are working on, never mind going over it every day in 15 minutes. It probably works better for siloed dev/product teams that stay under 30 people, but that's not how we work.
I share all this to give perspective on a pretty bold statement: "If you [don't like standups], then I don't want to work with you." Ten people is a good size for standups, and I think you may be overgeneralizing your experience when judging people who don't like standups.
Even still, I'm curious how much is changing daily to warrant daily standups? We have a rotating "release team" who runs QA and ultimately performs releases, and they check in daily. But daily checkins for feature development seem very frequent to me.
That's interesting, thanks. So a dev can be working on a feature over an open ended number of sprints? What is the significance of the sprint, then?
We don't have "planning cycles" except for quarterly prioritization to realign on which features matter the most (exceptional features occasionally get prioritized outside the process). When you finish one project, you pick another that's interesting to you that's near the top of the priority list, with support from our Product team and Engineering Operations.
This article, as with much tech discussion I've seen in the past 5-10 years, seems to take sprints as a given. Are most devs here working in a sprint model? It sounds a bit soul crushing to me to be "continually sprinting".
I'm so glad that our company doesn't have them—I think it's a significant factor in me grinding it out for 9+ years. We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release.
I feel like it gives me a lot more agency and ownership of my work. I think it's the right amount of subtle deadline pressure, relying on my intrinsic motivation to get my feature shipped and move onto the next one. Or to have the freedom to determine that it's not ready yet and spend a little more time to avoid shoving out a pile of technical debt.
I'm curious to see what I'm missing, though. Anyone love sprints? Anyone working in a non-sprint model and hate it?
I vaguely recall research about process changes reliably boosting productivity temporarily but eventually reverting to the mean. Does anyone recall if that effect has a name or a canonical study?
You are correct that this presents a very good, easy-to-install piece of functionality for Windows users. The Windows shortcomings that you point out are certainly problems, and I think that your software does a good job of overcoming that.
The part about efficient background sync is a good point, too. I have noticed some minor lagging using curlftpfs in Linux, and that might be something that would make for a better solution in the Linux world, so thanks for that idea.
Your use-case described in #2 does make sense, but I still agree with others' comments here that claiming that it replaces USB drives is a bad idea in general. All of your feedback was well-thought-out and appreciated; I only hope that I was able to give you a sneak preview of some of the potential criticisms you may receive. Best of luck to you!
1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
2. It doesn't actually replace a USB drive. Most people I know e-mail files to themselves or host them somewhere online to be able to perform presentations, but they still carry a USB drive in case there are connectivity problems. This does not solve the connectivity issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?
You might want to check out FUSE for Linux. There are various programs built on top of it which allow remote filesystems to look exactly like local ones. Two that I use are curlftpfs and sshfs. It's really nice to be able to perform any of my computer's programs on these remote files, and it looks very similar to what Dropbox accomplishes. Of course, you would need to have an FTP or SSH login somewhere, but you can get free FTP access from e.g. Lycos, so that shouldn't be an issue.
In short, I guess I'm curious what separates Dropbox from using a free FTP service which is connected either through Windows' built-in Network Places or Linux's curlftpfs. There are obvious differences, but are they enough to warrant fees?