The only feedback you get as a sole developer are your compiler and errors in production. You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.
> How do you know that what you are doing is a “mistake” if it works?
It's a good question, one that's a good nod towards the principle that you will inevitably learn more slowly if your own mind is the only one you have to work with (and lately I've been thinking about how I can get in a professional position where I'm near the bottom end of the intelligence and/or domain knowledge range in the room for this very reason).
But one answer might be: you'll know. "Works" is shorthand for satisfying a certain set of expected conditions. There's a core of reliable behavior in the software that's the minimal working definition of "works" ... but there's also the question of relative ease when it comes to reading, understanding, and changing/augmenting the code you have, or how the code "works" as an expression of the system for the purpose of presenting an interface to the developer.
Chances are pretty good you know the feeling of writing something that you either (a) are uncertain is really adequate as far as the developer experience goes or (b) you know is probably not adequate but seems to get you to the minimal definition of "works" fastest.
Listen to that feeling. Interrogate it. Try something different. Observe the tradeoffs.
It is a "mistake" as soon as the work gets to be too much for one developer and the company brings in some more developers.
By this time, that one inexperienced developer gets promoted to "Architect" because he knows where all of the bodies are buried. Now one of two things happens. He brings in more inexperienced developers because he doesn't know what a good developer is and they keep adding on to the UserManager class and to organize it better, they add section breaks. The class grows.
If they are lucky, they get an experienced developer who tries to tell the "Architect" about proper coding techniques, management and the architect dismisses the critique as "if it ain't broke don't fix it"/"this is the way we've always done it". All of the good developers leave and you are left with only bad developers.
So even if you see that your 10K line UserManager class is hurting your velocity and you are spending more and more time maintaining your AcmeDatabaseManager and AcmeLogManager, you still don't why it's taking longer or what to do about it.
Problem solving doesn't work like that. Many comparable issues have been found and solved by different people at different times, in parallel, unknown to each other.
With as many people as we have on Earth it is unlikely that one special unique problem can only be solved by one special unique person. While it might happen, it's unlikely to happen to a software developer at a small company. The problems and solutions you find there are often relatively comparable or even generic, and are found and solved by many people in parallel at the same time. While working together might be faster, it has nothing to do with the feasibility of detecting and repairing issues.
You're going to want to follow the best practice, that no file should be longer than 2 lines of code. One line for imports/requires. One line for a massive one liner.
You've triggered my PTSD with the phrase "UserManager class". Seriously, OOP can be such a foot-gun sometimes. Dozens of wrapper classes and manager classes might be the sign of a cluttered mind.
How do you know that what you are doing is a “mistake” if it works?
Reading. Plenty of books, blog posts, and forum posts point out that you shouldn't have "10 KLOC UserManager classes".
The thing is, one has to figure out how to integrate "book learning" AND real world experience, so that they're constantly synthesizing a newer, better understanding.
Funny thing is, if you look at codebases of some opensource projects [1] doing complex and ambitious stuff, written by some real experienced engineers, you’ll see the common „dogmas” (don’t have long classes, don’t have long methods etc. etc.) are not obeyed. And yet, they shipped very complex and successful software. It’s almost as if these rules are mostly arbitrary and don’t really matter.
[1] I’ve noticed that in codebases of Apache Spark, Apache Oozie, Apache Cassandra, and Firefox.
It’s almost as if these rules are mostly arbitrary and don’t really matter.
Definitely. I mean, some of them probably have some objective basis. But clearly some of them are indeed subjective and arbitrary. Take "long method names" for example... I believe method names should state what they do, and should be however long it takes to do that. To my way of thinking, making a method name shorter just for the sake of being shorter, and eliding semantic information, is an anti-pattern, not a best-practice. shrug
I wrote some really long functions in C back in the day just to avoid the overhead of function calls. Yes, this was after running a profiler and we had massive amounts of data (for the time) to crunch within a short window.
Yes. I would also include reading other more-experienced developers' code in bullet point #3. Pick a well-respected project from a language you're looking to get better at, and dive in.
10K line UserManager classes “work”.
That’s how you get the “expert beginner”.
https://daedtech.com/how-developers-stop-learning-rise-of-th...
The only feedback you get as a sole developer are your compiler and errors in production. You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.