HN Explorer

Imposter syndrome? Or am I that bad?

8 points by acquiretoast ↗ HN
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'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.

Now, all that sounds faintly impressive as a one-man job. Not exceptional but it's decent enough. However I know what'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.

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's true or not...

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.

What would you advise in my situation? There'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'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've just been unlucky?

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.

4 comments

[ 0.19 ms ] story [ 24.1 ms ] thread
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.

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!
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.