So, I feel like a total noob when I show my work to other people. I'm trying to focus on some of my ideas and build out a company around something I can manage to build to 80% and start demoing. Here are my doubts:
- I don't really understand how CI works. At work our CI process is massive and honestly confusing/complex. In my case, I have just a few simple scripts that manage this.
- I keep my code organized by separation of concerns using some things I've learned from clean code, clean architecture, DDD, etc. Almost everything is a single responsibility, small functions that I can test easily in isolation or as part of larger integration tests, and I don't really do anything fancy or n levels of abstraction, factories for factories, etc.
- If it works out of the box with std library, I use it. Otherwise for more complex things or things I don't personally understand, I'll use a well supported library if I don't want to spend a whole day re-inventing the wheel.
When I look at other people's code I often have a really hard time understanding what is going on. The tests are confusing, and I feel like I am stupid for not understanding what they're doing in the source code. I also find a lot of the "support" projects like CI, infra, etc. are also complex. At work we have entire teams for all of this, like there's a dozen engineers who work on CI related things, like 30 in infra, etc who support all the teams. Maybe that's why it is complex?
At work I'm considered pretty good and I get put on greenfield projects which I hammer out foundations that other people then pick up and build on top of. When I look at external projects or work other people do, I often times just get overwhelmed by the complexity in these projects from the libraries they use to how they structure their code or tests.
Every once in a while I conclude that the code or infrastructure defies my abilities to understand it. But most of the time I conclude the developers just made it all too complex. That can happen because complexity got equated to skill or prowess, or it can happen organically over time. A lot of the time new people come into the team, and rather than take the time to understand what works and adapt to it they declare it "unmaintainable" or "shit" or "not modern best practice" and write a parallel system to their liking, or add layers to hide the parts they don't like, turning a small mess into a bigger mess.
Programmers tend to learn a few languages and tools and stick with those, even when their tools start to impose limitations or add more complexity than necessary.
Brian Kernighan said "Controlling complexity is the essence of computer programming." The best way to control complexity is not to introduce it in the first place, and to eliminate it when you run into it.
The fact that you write testable (and tested) code, and that your CI needs are met by simple scripts is a good thing. I personally try to ensure that all CI can be done locally, and that basically forces you to just use shell scripts (or make, or similar — but to keep it simple)
Working on something really big means that you only do a small portion of everything that needs to be done. You might write unit tests for just the component you work on, but integration and user tests are handed over to the testing team. CI has its own team. Architecture, UI, database, documentation, etc. might have their own dedicated teams. Each team develops deep domain knowledge in their area and often optimizes and customizes it to death.
When you start your own thing, you have to do everything. MAKE files are not created for you. All the design and customer relations are now part of your duties. Sales, marketing, support. The solo developer has many hats to wear and you have to understand all of it.
Happens to everyone.