
Imposter syndrome? Or am I that bad? - acquiretoast
I have been contracting for a startup for a couple of years now and have built them a pretty substantial system - this includes various cross-platform mobile apps, landing pages, admin panels, dashboards, API&#x27;s and a ton of background jobs processing GB of daily data updates (along with constant normalisation of this data and processing of various user events with it). This system is basically the entire product and supports a dozen or so staff, turning over a few million per year.<p>Now, all that sounds faintly impressive as a one-man job.  Not exceptional but it&#x27;s decent enough. However I know what&#x27;s behind the scenes: lots of PHP code on old frameworks, no tests, super hacky code in a lot of places and no cohesive overall architecture or design docs to speak of. Some of this  I can explain away given time constraints - everything  is urgent (yeah, I know), general startup needing to move super quickly and so on, but the rest of it is myself.<p>I sometimes justify this to myself as tiredness or burnout and just not having the energy to go the extra (required?) mile - but whether that&#x27;s true or not...<p>However, now we are at a point where new recruits are going to be coming in and I can feel my days are numbered. One look at some parts of the codebase and I know what will be said.<p>What would you advise in my situation? There&#x27;s just no way I have the time to refactor and update everything (2 new apps need be built!) - if indeed I have the full ability to do so. Should I just accept the inevitable and start looking for new work? I&#x27;ve seen new devs come and immediately declare all code terrible and push for rewrites too many times to not expect it, but maybe I&#x27;ve just been unlucky?<p>Or am I overthinking this? Any perspective from those who have been in a similar position would be most appreciated - or indeed a founder who has been in this situation. TIA.
======
byoung2
I've been the incoming dev on a project like this. The CTO (a brilliant
architecture guy who hadn't written code in a long time) built a proof of
concept in a spaghetti of c# and PHP (drupal). It was an absolute mess, but it
worked. It was actually impressive that he was able to build it all solo, and
obviously with a team and infinite time he could have made the code pretty.

You have accomplished the same thing, which is building and shipping a whole
app, which some of these incoming devs have not. Your job now can be to guide
these devs in refactoring the individual pieces of the app while you keep an
eye on the bigger picture. Think of a conductor in an orchestra...he can't
play every instrument perfectly, but he can guide the individual musicians.

~~~
PaulHoule
Plenty of times people get a big team together and make something that is a
steaming pile of poo.

More resources and more time are good if you put them to use effectively, but
not everyone does.

------
ctrlaltdev
Doing everything by the book, or according to the guidelines some random
person published on Medium last Wednesday is a luxury we don't all have.

You have the merit of having done all that, and it works.

Now, sure, don't we all, to some extent, want to change everything when we
arrive in a new environment? IMO, it comes down to a couple of things:

\- Who make the choices of refactoring an app or not?

\- What's the company roadmap.

To avoid being showed the door, I would advise you to support refactoring.
Show enthusiasm and support. You could be the guy with the knowledge on how
everything has been done and why, and that is greatly valued if the decision
to refactor some app is made.

Eventually, the decision to do so will depend on time and money.

------
jk_danson
You should discuss the code base with your contact and let them know the
scenario. Also, if you don't tell them I doubt they'll fire you for you are
the resident expert. If they let you go, they'll basically be just be status
quo for a long time while the new hires fix the working "mess" and figure out
how to tie in 2 new apps. If these new recruits are for you to supervise, all
the better. You'll be able to refactor the code faster and they will become
very familiar with the system. Good luck!

