Ask the main part of your question in the title. This should be concise but informative.
Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.
Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.
Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
Every project should start by having well-defined specifications.
And should have some Quality&Testing involved (ideally independent) that will check that everything you have developed answers to the specifications. But nothing more.
If you go beyond the specs, it's overengineering.
ETA: remember that normally you're not trying to create something perfect, you're just answering the needs of a customer. You're paid (hopefully) to fulfil these needs and nothing more
(Customer) specifications rarely have technical implementations described down to the most basic detail though. It also won't account for every possible technical problem that could arise, customers generally don't know or care about those.
Maybe if you're a junior in a very professional and experienced company, you can expect the perfect documented jira ticket that could be at that point solved by putting it into chat gpt, but in most cases you will be expected to solve and anticipate the unknowns, especially if you're in a more senior position.
I used to manage project deliveries for critical software. Around 10 years in this role. My job was mostly to tell the project manager who wanted to please the customer that if he wanted all the bells and whistles he had to ask for it formally because the team was not being paid otherwise.
If you don't have the specs, you have to push and ask for them. Get the involved people in as many meetings as you need until everyone agrees. At least in my field. You can't guess what the customer wants. The specs are a contract and protect you from future moronic questions from the customer. It is extremely useful to take the time to do them right, otherwise the customer will always find a way to fuck you over.
So I don't agree at all that in a senior position you have to magically know what to do. It's a recipe for disaster. The more senior developers do the strict minimum.
Were your project managers always so technically capable? In my experience they represent the business and while they have to ultimately sign off for the development to start, they don't come up with architecture and design of the solution itself - that should come from the developers/engineering team. At the very least the devs propose possible options and their costs/tradeoffs and then the management picks one, but it's not like they will come down and tell you whether you should use SQL, Postgres, Mongo or w/e database.
No they weren't technicals. I was the tech lead.
It looks very open in your case. Is there no standard or precedent for what you are doing? Something you could lean on?
Otherwise one of the old wise gits I knew used to say "we don't sell hammers, we sell holes in the wall", meaning you don't care about the tools as long as you reach the desired result.
Though in our case it was always only C/C++ so...
Anyway, what I would have done in a case like yours (and it doesn't necessarily apply) :
The methods, tools and design would be a discussion between me and the dev team
This is good advice, thanks. I will definitely get it written down and approved eventually, but the issue is with
It looks very open in your case. Is there no standard or precedent for what you are doing? Something you could lean on?
We're treading new water and doing stuff that nobody in the company is experienced with. We're getting some ideas thrown at us but that's the reason for this topic, I don't feel knowledgeable yet to decide if they are in the right or if they are selling us hammers they like while we actually need something else.
On the other hand, if I just do the simplest dumbest thing for an MVP, I am again just being a hammer and seeing everything as a nail when I should be learning, adapting and applying the correct tool? I kinda want to use the opportunity and do it better or learn something new.
The only way you know before doing it is through experience. If you don't already know you can make a prototype, or just guess and go for it - you might have to change it later though.
I would recommend prototyping when the cost of correcting a wrong decision later is going to be really high.
The other option if you don't have experience is just to copy what other people have done.
Aside from the commonly stated - experience:
The key point to keep in mind is that, at the end of the day, your building an application to satisfy a customer. Or to be exact, a list of requirements that may or may not be constantly changing. In this case from what i'm reading, I am assuming its your hobby project, so the 'customer' is you.
In this case, over-engineering is when you add more functionalities/services than what you needed to hit the bare minimum requirement. Ideally you want to hit basic requirements first, then start designing/engineering on top of what you have when your customer wants more features, etc.
Your design providing more features than the bare minimum should be an 'accident' more than intentional ideally, unless you think the extra feature takes 0% effort to implement. (Though TBH safe rule of thumb is, never design for additional unrequested features)
With the above context in mind, you should be asking the questions:
Yea, welcome to client engineering. Usually its handled by senior developers or project managers, unless your in startup.
TLDR; It's not about finding a design that is perfect, its about finding a design that is acceptable by the involved. What is acceptable? that is for the involved parties to decide.
Thinking you can even prevent all unkowns is a foolish endeavor. Only work on solving the problem at hand. Why would I think about some future requirement and lose sleep over it? That's the PM and sales team headache! Or think of it another way... you haven't yet reached the bridge yet but you're already thinking you need rope for the imagined bridge collapse.
All you can do with the present is make it relatively easier for your future self. Avoid complexity (thanks grug brained programmer!), don't tie yourself into knots and back yourself in corners (keep the code readable, testable and simple. This means minimal external dependencies, lose coupling but good coherence, and avoiding reinventing solution to difficult to solve problem)
some of these goals seem contradictory but you have to apply them to a specific problem and the objective of solving the problem (why are you solving this problem?). For instance, for crypto the advice of avoiding reinventing the solution takes precedence to minimal dependencies one because your objective is security which is important to get right without tolerance for bugs.