ask programmer for very general advice, they might say "learn to avoid complexity" or "embrace simplicity".
the only problem? it's really bad advice. it stinks, actually. absolutely terrible advice.
it's not because "experience is the best teacher" or "beginners don't have enough knowledge to apply this advice," but that in eschewing complexity, you often create something worse in your quest to eliminate it.
not to be all "conservation of energy" here but when someone tells you they've eliminated complexity, it usually means the complexity is now someone else's problem.
ask a programmer to write a "simple tool" and sure enough, you might get back something with only a few lines of code, and maybe just a handful of features—but you'll also get back a tool that takes eighteen command line switches and maybe a yaml interpreter. if you tell them you might change your mind later, the code will have a plugin engine, too.
similarly, you can write a EULA in basic english but that does not make it any more readable, or any more enjoyable to read.
building a simple tool doesn't mean building an easy to use tool, and building something out of simple parts doesn't make for simple results, either. in practice, there aren't really any examples of simple code: there's only code that has no responsibilities, or code that doesn't manage its responsibilities. code in the real world does not have either luxury.
a lot of the time, code ends up looking that way because it has to—we call it an abstraction when we like it, and indirection when we don't. meanwhile, simple, easy, clean, good, these are words that describe how the person feels about the code, often how much pride they take, and not much else.
ultimately, complexity it isn't some inherent property of code in isolation, but how that code interconnects with the other parts of your system, human or computer—something can be complex to one person and simple to another.
when someone says "that code looks complicated" they usually mean "i wouldn't have written it that way" (and when they say "this code is simple" they often mean "please buy my cloud database product")
that said, so, so much complexity has been created in the name of building "simple reusable code". for some reason, many programmers believe the simplest solution involves writing a framework and yaml interpreters. i don't know who to blame.
in the end, the only complexity you can avoid is the complexity you add yourself. it's pretty easy to avoid: you err on the side of under abstracting until you make a mess, then err on the side of abstracting again, when the mess gets a little more manageable, and move on with your life. it doesn't matter how complex something is if you never have touch it.
be warned: changes get made in the easiest place to make them, and if you don't tidy up after yourself, you'll quickly run out of easy things to change.
as for asking "is this simple", or "is this complex?", you'll be better off asking "will this make anyone happy?" and occasionally adding "really?" just to be sure.
talk about what needs you have and if the code will meet them. talk about how much time you can afford to spend on the problem, and how much you're willing to spend. talk about responsibilities and if any of them can be shifted elsewhere. talk about the dev team, too.
so, my advice to beginners?
add some words to that Readme. make the error messages a bit nicer. maybe reject bad inputs earlier. worry about documentation. meaningful tests that help find bugs. try limiting the impact of the cheap hacks. oh and don't put all the util functions in one file, they always get tangled.
don't worry about complexity. worry about your users.
remember: beginners can create an absolute mess, but only an expert can get paid for it.
