3 ms·

That's a great list and echos what I have noticed about developers I want to emulate as well. Any tips on how to be "Maintenance focused more than feature focu

That's a great list and echos what I have noticed about developers I want to emulate as well. Any tips on how to be "Maintenance focused more than feature focused" if the culture is focused on pumping out features on tight deadlines? I have, of late, found myself engineering more on nights and weekends—trying to clean up and refactor the code that we have to pump out to meet the deadlines. However, I'd love to find a way to make that kind of work part of the day to day.

technofiend 8y ago
>Any tips on how to be "Maintenance focused more than feature focused" Honestly this is more "how do I keep from having to perform maintenance" but just spitballing... Do you have defined Service Level Objectives (SLOs) for your APIs? Do you have unit tests so you can both prove changes do what's needed and that nothing else broke (regression testing). Do you have good error handling and readable error messages or is that all #todo? Are your processes idempotent? Is there a documented and automated recovery procedure if not? Add all the features you want, but if you build them to have a high uptime and resilient up front you're really combining a view into maintenance (or more importantly - not needing it) while still delivering features. And if those things aren't true then I guess making them true first before adding features is sort of what the original poster meant?
austincheney 8y ago
Spend a lot of time on reported issues from users. If a user is willing to spend time to report a defect spend time to ensure you really understand what they are reporting and solve it as completely as you can. Don't wait for users to report defects. You have to constantly use the software you write. Stress the hell out of it and really try to make it fail. Write tests to ensure the edge condition is covered against future regression. Attempt to automate everything. Adding new options and features in the previous version of my application was a pain in the ass. Now they are all listed in a single JSON file. The build adds the options into the supported interfaces as well as the documentation. Now all I have to do to add a new option is update the JSON file, add the desired result into the application logic, and write tests. Ensure your documentation is well structured. You want to ensure all the features are mentioned, but its helpful when reading the docs if there is a uniform organization that explains the purpose, data type, compatibility, and options of each feature. The challenge with supporting many features is that collisions of various features can result in unexpected outcomes. You have to really look for these things before your users do.

technofiend 8y ago

>Any tips on how to be "Maintenance focused more than feature focused" Honestly this is more "how do I keep from having to perform maintenance" but just spitballing... Do you have defined Service Level Objectives (SLOs) for your APIs? Do you have unit tests so you can both prove changes do what's needed and that nothing else broke (regression testing). Do you have good error handling and readable error messages or is that all #todo? Are your processes idempotent? Is there a documented and automated recovery procedure if not? Add all the features you want, but if you build them to have a high uptime and resilient up front you're really combining a view into maintenance (or more importantly - not needing it) while still delivering features. And if those things aren't true then I guess making them true first before adding features is sort of what the original poster meant?

austincheney 8y ago

Spend a lot of time on reported issues from users. If a user is willing to spend time to report a defect spend time to ensure you really understand what they are reporting and solve it as completely as you can. Don't wait for users to report defects. You have to constantly use the software you write. Stress the hell out of it and really try to make it fail. Write tests to ensure the edge condition is covered against future regression. Attempt to automate everything. Adding new options and features in the previous version of my application was a pain in the ass. Now they are all listed in a single JSON file. The build adds the options into the supported interfaces as well as the documentation. Now all I have to do to add a new option is update the JSON file, add the desired result into the application logic, and write tests. Ensure your documentation is well structured. You want to ensure all the features are mentioned, but its helpful when reading the docs if there is a uniform organization that explains the purpose, data type, compatibility, and options of each feature. The challenge with supporting many features is that collisions of various features can result in unexpected outcomes. You have to really look for these things before your users do.