> Working alone means you don’t have to share the context of your changes with others.
This is the #1 advantage. It's huge.
I have a mind that can hold a great amount of detail, pivot, and reshape architectures; all, without writing down a thing. I can do big things, very quickly, and make adjustments on the fly. It's pretty cool.
If even one other person becomes involved (at the technical level), the whole shooting match comes to a screeching halt, as the overhead introduced by team communication is gigantic.
I have learned to break down team projects into units that can be done by engineers, working alone. This works best, when the engineers are experienced, and are very much "on board" with the development goals and heuristics. It doesn't work so well with inexperienced engineers, or ones that have not been involved previously (new hires).
That said, big things pretty much require a team. That means that the overhead is inevitable, and it is up to the managers to create a system that maximizes engineer agency, and reduces team overhead.
Actually, future you will be confused. And if your project scope increases, then you might become less effective.
I highly encourage you to use a project issue tracking system even for yourself. Describe the issues before doing them. Also describe the current state of the system in a wiki. Keep it up-to-date. Then you can attract people to make changes here and there and take ownership of small parts of your system.
The main principle is that the producer should spend 3x as much time on refining and presenting what they have done, because that will save each consumer a little bit of time and has compounding effects.
You’re writing to “future me.”
I’ve been at this for a long time, and regularly have to revisit my codebases (I have quite a few). I also tend to use many of the packages that I publish, in my own work (dog food). I write code that I want to see, six months down the road, and my bar is fairly high.
I am very familiar with various devops infrastructures, having maintained many systems that integrated things like Jenkins, JIRA, Confluence, Perforce, BitBucket, Bamboo, etc.
These are pretty much required, when working as a team, but they introduce some significant overhead, and not just in the work needed to establish and maintain them. They also introduce overhead into the workflow of each user of the system.
For my personal feature tracking, I use a PostIt pad, on my desk. I have a glass-top desk.
As I plan a feature or bug fix, I write it as a task on a PostIt, and stick it on the left side of my desk.
As I work on it, and consider the task complete, I move it to the right side of my desk.
Once I have tested, confirmed, and checked in the fix, I drag the note to the trash (under the right side of the desk). I use the commit comments to codify any historical notes. I will, sometimes use a GitHub Issue to codify something for historical stuff; especially if it's something that a "non-me" stakeholder is interested in, but the PostIt for that issue is what I use. I think the largest number of PostIts that I've had, over the last couple of years, has been 4.
This only works for two main reasons:
1) I’m really experienced, so I’m pretty good at estimating and wargaming the tasks; and
2) I run in what I call “constant beta.” That means that I don’t move on to a new task, until I am satisfied that all bugs have been fixed; even the small ones. Incomplete implementation is not usually considered to be a “bug,” but it depends on the current context. Bugs don't usually last long enough for me to write them down. I'm fairly efficient at problem-solving.
#2 is a biggie. My apps are generally at “ship Quality,” almost from the start, although incomplete.
This allows tremendous iteration, especially in receiving feedback from non-tech stakeholders (I can start using TestFlight to share releases, from the very earliest stages of a project).
It also prevents those disastrous “Oops, we didn’t think of that in our project planning” issues, and also pretty much guarantees a smooth, surprise-free final testing phase.
This is especially useful, when you have a small, distracted team, like many volunteer and nonprofit orgs have.
But this is what WFM. YMMV.
You can see for yourself, how I work: https://github.com/ChrisMarshallNY#browse-away
https://github.com/Qbix/Platform
It takes care of everything from MVC to WebRTC to PaymentRequests to Web3 to Videoconferencing, and soon avatars and metaverse etc. You can literally build almost anything with it, quickly, and get it to MVP stage.
I architected it all. I had to hire developers to help me with it, and it took them years to get up to speed. My biggest source of loss and inefficiency in business was worrying that one of them would leave, after many years. Thus I constantly paid them their salaries and slightly increased them. As you can imagine, this was tough to do as an individual, so we took on projects, investors, etc.
Now, I am in full control of my two companies, and finally taking on VC and crowdfunding: https://wefunder.com/Qbix
Yes, the capital infusions can really take the company to the next level. But I can tell you that, had I been documenting (and making everyone else document) every component from day 1, we could have done a lot more, a lot more efficiently, and attracted a lot more people to our projects on GitHub. (Not that we tried, but all of these things compound and every step in the "conversion process" of a new developer would be more likely to convert). The following have helped a lot:
https://community.intercoin.org and https://community.qbix.com
https://youtube.com/c/intercoin and https://youtube.com/c/qbixplatform
This is just like when you make an app and make the UX good enough that users can actually onboard and invite friends.