> everything that I have done is being scrutinized by all new team members. It's really hard to deal with that constant barrage of "why did you do it this way"

Reading old code with a critical eye is an important part of working on a mature code base.

If an arrogant developer reads some questionable code, they will think "the author must have been stupid." They will ask this question as a way to satisfy their narcissism.

If a thoughtful developer finds some questionable code, they will think "the author must have had some motivation that I don't know about." They will ask this question to help them understand the system design and do better work.

Both attitudes lead to the same question. You could start by assuming your new team members are thoughtful and want to learn. They will understand that "we were under time pressure" or "we didn't know about xxxx technique" is a valid answer to "why did you do it this way."

If you discover that your new team members have narcissistic tendencies, then you have a much bigger problem than justifying your own past decisions.

One thing to keep in mind with respect to that - often when teams grow you get more ivory tower types. Not that everyone wants to build an ivory tower, but you do get a lot of in-between. One thing to keep in mind about why the code was the way it was - it was designed that way to grow the company fast and to get customers. Nearly all companies that start that growth will face the inevitable - let's rebuild all of this from scratch. It doesn't mean your original contributions were worthless - no one would be working there if that was true.

In the end you may move more towards explaining to people how the company operates, how the data is processed and keep that going.

Oh I have been in a similar position myself. Was a single dev in a startup and I needed to cut corners. I implemented everything. From embedded controllers to user interface and I even used code that some students wrote as a proof of concept to save time. Codebase was a mess. It worked in the end, but barely and maintenance was horrible.

I demanded help when the product was on the market and the new dev began to refactor parts of the software. Was awesome to have help and the new dev teased me when he discovered my greatest sins and most idiotic decisions that I committed. Wasn't meant seriously from his side, but at some point it nagged on me nonetheless because he was a bit of a smartass at times.

Helped me to reflect what I implemented with the resources and time that I had. You will rarely be happy with the code and design decisions you made yesterday anyway. Learn from the mistake and move on. A dev that never wrote bad code probably didn't write much to begin with. People that constantly question design decisions often might just want to prove themselves to you or honestly want to know why you did it. I often answer something like "I was full of optimism about it at that time".

I'm not in a startup, but you should comfortable answering/acknowledging something along the lines of we needed it working quickly, and this did the job for x amount of time based on the time available at the required throughput.

We have the time now for refactoring ... or we'll add a ticket to the backlog, etc.

Second, everyone looks at some code, wonders what idiot did this ... and at some point discovers it was themselves x months/years ago. If you're the primary coder, you'll be getting this a lot. Accept that you've learned and improved since then.

Hope this helps.

Yea that is about right. Given the knowledge and requests I had at the time I solved it the best way I knew how. No one opts for worse it just happens from time-to-time given business constraints.

I all too frequently wonder who wrote this and see that it was me. You're right that it's a good sign of growth :).

I assume you built things in questionable ways because as you said, the company was growing like crazy and there was no time to “do things right”. It just had to work. It sounds like you did a great job if the company is currently doing well.

My only advice is you should be open-minded to the newer devs who work day-to-day with the “legacy” systems you originally wrote and may have very informed ideas about how to improve or refactor those systems. It’s not a knock on you, the company is simply in a different stage.

I had this exact same experience at a previous startup. It was really frustrating to me, it was so easy for new devs joining the team to criticize past work. It was especially difficult for me because I'm not a natural leader and I tend to avoid conflict. On top of that, I already knew I was cutting corners, it's just impossible when I was the only developer and was forced to make tradeoffs and meet deadlines all the time. But the new team members weren't around for those times so they were blind to previous state.

I'm now working for a different startup of very smart people and engineers and see that it's just normal to have all kinds of tech debt. My previous experience has given me valuable perspective, I don't complain about how/why things are the way they are I just do the best I can to improve it and ship features.

>we built things in questionable ways

Classic. I know brilliant people who wrote pretty ugly code years ago and beat themselves up about now (in a tongue-in-cheek way -- they joke about it frequently).

Coding is hard; if it was easy, people as smart as them would've written stuff perfectly the first time!

Humility is very important for coding (most things, really). Everyone writes "questionable" or "ugly" code, so it's important to accept that as much in yourself as you do for others. Think about what you would say to someone else in your position: would you be as critical of them as you are of yourself?

Moreover, in the early days of a new company, the priority is to get something working to create income - sometimes, quality be damned. Otherwise, there's a good chance the company won't survive to get the chance to hire people who will get the opportunity to criticize the code that made their employment possible.