4 ms·

This is what did it for me as well. Even when it was technically outside the requirements of my job, I started stepping up and actually fixing my own shit. And

This is what did it for me as well. Even when it was technically outside the requirements of my job, I started stepping up and actually fixing my own shit. And not just bugs or issues, but really feeling the pain of having to deploy it, talk on the phone with the customer and feel the lack of help/debugging stuff built-in to the product, train new users on how to use it, feel the panic as you realize that you cocked up the last deploy and it's going to be offline for like an hour while you scramble to roll back the changes which you thought you figured out months ago but everything changed since then and you are sitting there with nothing. Slowly but surely I started adding things to my "never do again" and my "needs to be done before launch" lists.

FLUX-YOU 10y ago
I have a position like this. It sucks. If you have to take total control of at least project, you'll likely be doing it for all projects. If the previous project was created by multiple people, but you are now the sole maintainer, it will take more time to work on than the other projects. These are the ones for which you should know like the back of your hand when juggling 10 other low-impact, one-man-army projects. Lack of QA and Ops means you are limited by your own working set of skills, which is most likely going to be shallow in those areas. It's also very hard to learn dealing with customers on the job in this role -- it's best to have learned it somewhere else. You can write unit and automated tests, but that increases your development time 3 fold (not to mention you already need good unit testing and automated testing skills). You will feel like you are constantly drowning. The highs are not really that high and the lows are very low. There is no opportunity to master anything other than making the customer happy for a month or so, which is really only so you can meet other customer needs. You may not have an additional person just to bounce technical ideas off of. This is so much bigger than you can realize if you've gotten used to this kind of one-man-army position, chiefly because you often have little time to actually think about what would make the products better. None of this feels like growing, only surviving, especially if the next position is going to be a place that has experts in all of the extra areas.
- Klathmon 10y ago
  In my situation, it was a greenfield new-project which kind of started off as a "moonshot" and became a real thing, so mistakes and extra development time were much more tolerated (not to mention my employer is pretty awesome!). It's not ideal, and I'm actually happy to be moving out of that (with what used to be my "one man army" project actually getting a team and managing it). But holy hell did it teach me a lot!
- busterarm 10y ago
  Me too :(
jacobevelyn 10y ago
Could you share some/all of your "never do again" and "needs to be done before launch" lists?
- deleted 10y ago
  [deleted]
- Klathmon 10y ago
  A lot of the don'ts are kind of domain specific (and the rest are kind of "don't do the opposite of the "do" column), and the majority of the "dos" are the kind of thing you always hear everyone saying, but once you've felt the pain it really drives the point home: * Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind) * have a deploy plan that is one step * have a rollback plan that is one step * have backups running way before launch * have one-step restores from backup running before launch * make sure your restores make their own backup before running (yeah... that day sucked) * write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks * document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!) * make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!) * Have someone that is not a developer use the app without any documentation (this is huge) * Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work) * build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable) * Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with * make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master * plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here... * stick to a style guide * put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc... And a lot more i'm probably forgetting...

FLUX-YOU 10y ago

I have a position like this. It sucks. If you have to take total control of at least project, you'll likely be doing it for all projects. If the previous project was created by multiple people, but you are now the sole maintainer, it will take more time to work on than the other projects. These are the ones for which you should know like the back of your hand when juggling 10 other low-impact, one-man-army projects. Lack of QA and Ops means you are limited by your own working set of skills, which is most likely going to be shallow in those areas. It's also very hard to learn dealing with customers on the job in this role -- it's best to have learned it somewhere else. You can write unit and automated tests, but that increases your development time 3 fold (not to mention you already need good unit testing and automated testing skills). You will feel like you are constantly drowning. The highs are not really that high and the lows are very low. There is no opportunity to master anything other than making the customer happy for a month or so, which is really only so you can meet other customer needs. You may not have an additional person just to bounce technical ideas off of. This is so much bigger than you can realize if you've gotten used to this kind of one-man-army position, chiefly because you often have little time to actually think about what would make the products better. None of this feels like growing, only surviving, especially if the next position is going to be a place that has experts in all of the extra areas.

Klathmon 10y ago
In my situation, it was a greenfield new-project which kind of started off as a "moonshot" and became a real thing, so mistakes and extra development time were much more tolerated (not to mention my employer is pretty awesome!). It's not ideal, and I'm actually happy to be moving out of that (with what used to be my "one man army" project actually getting a team and managing it). But holy hell did it teach me a lot!
busterarm 10y ago
Me too :(

jacobevelyn 10y ago

Could you share some/all of your "never do again" and "needs to be done before launch" lists?

deleted 10y ago
[deleted]
Klathmon 10y ago
A lot of the don'ts are kind of domain specific (and the rest are kind of "don't do the opposite of the "do" column), and the majority of the "dos" are the kind of thing you always hear everyone saying, but once you've felt the pain it really drives the point home: * Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind) * have a deploy plan that is one step * have a rollback plan that is one step * have backups running way before launch * have one-step restores from backup running before launch * make sure your restores make their own backup before running (yeah... that day sucked) * write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks * document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!) * make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!) * Have someone that is not a developer use the app without any documentation (this is huge) * Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work) * build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable) * Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with * make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master * plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here... * stick to a style guide * put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc... And a lot more i'm probably forgetting...