3 ms·
Step 1 - Get a remote contracting job where you are the sole engineer on a specific part of the product, like a mobile app or web service. Step 2 - Work real h
by valuearb 6y ago
Step 1 - Get a remote contracting job where you are the sole engineer on a specific part of the product, like a mobile app or web service.
Step 2 - Work real hard on building a large undocumented code base. Get a reputation for speed and responsiveness.
Step 3 - Gradually do less and less while billing the same hours. Truthfully tell them that the code base has gotten so complex changes take a lot longer. Rely on your previous reputation to keep them comfortable with that.
Your client will likely accept all this at face value. Even if they get frustrated, no one will want to take on your large mass of undocumented code.
You can probably milk this as long as the product remains funded. The major risks are product cancellation or worse, high product success that leads them to want to invest more into development. Barring those two unlikely events you likely have years of coasting ahead of you.
- treelovinhippie 6y agoBasically my current contract at a startup funded by a bank. Though I started off doing fast work only to realize that the CEO/PM has a fetish for feature bloat, and entire sections of the app get changed by the designers within 2-3 weeks of the previous changes. So the code base is naturally a complicated mess. I learned quite quickly that to maintain sanity the key was to do the work as quickly as possible, and then sit on the commit for a few days while I work on my own projects. I'm still delivering at an expected speed but probably average 2 hours/day of real work with the occasional full days leading up to prod release. I keep Slack open throughout the day to give the illusion of 9-5, but then there's the context switching issue if you get pinged at 3pm. Capitalism is such a joke. This system no longer functions for human life.
- lytefm 6y agoSounds like a good advice. Even better if you're good at working with someone else's legacy code who had already left the company. At my first job, it often took me several days to find bugs that were often fixed by changing very few lines of code. Nobody would have noticed if I hadn't done anything for a whole day other than answering occasional messages.