4 ms·

Wow your comment really made me think. I too have been in the industry for over a decade. Thinking back, I can not think of a single manager or lead that I wan

Wow your comment really made me think. I too have been in the industry for over a decade. Thinking back, I can not think of a single manager or lead that I wanted to be like, as well. In fact, because of my last horrible manager, the worst I've ever had, I want to exit the industry all together. I just want to go my own way and have my own small business.

NAHWheatCracker 8y ago
In fact, because of my last horrible manager, the worst I've ever had, I want to exit the industry all together. I consider myself lucky to never had a truly horrible manager. I just want to go my own way and have my own small business. If only it were so easy.
- kilroy123 8y ago
  You're telling me! Software engineer != Entrepreneur It's been a brutal run so far. I'm failing at it and it's hard not to tie your self-esteem and self worth to it all.
austincheney 8y ago
All the people that I wanted to be like, growing up as a developer, were people who seemed more focused on their programming hobby than their programming job. Here is the take away that I noticed about those people and have attempted to apply to myself: * Extremely focused on product quality and defensive code * Maintenance focused more than feature focused * Excellent with documentation * Indirectly focused on self-promotion by writing good books or producing beneficial tools * Never directly focused on self-promotion It is so easy to get bogged down with bloated, dependency heavy, framework bullshit at work that product quality is distantly lost. When writing important software as a hobby you don't have to conform to a lowest common denominator for acceptance by new hires.
- adregan 8y ago
  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.
sixstringtheory 8y ago
I had a crisis similar to what you describe about a year and a half ago. I still wrestle with whether or not I want to stay in this industry. Client acquisition has been its own brutal process, although working remotely no doubt adds to the difficulty. I’m lucky enough to travel with my wife, who has a good job in a different industry, which has helped buffer the difficulty in landing consistent remote work. I definitely don’t regret my decision because I’m happy to busy myself with hobby or non-tech work, but just make sure you’re aware of the risks. I wish you and anyone considering the same the best of luck!
hef19898 8y ago
Isn't it incredible how much one bad manager can make you think about leaving a domain you genuily like and are really good at? Best thing to do, from my experience, is to take some time off (if you can afford to) and get your head clear. Distance really helps.

NAHWheatCracker 8y ago

In fact, because of my last horrible manager, the worst I've ever had, I want to exit the industry all together. I consider myself lucky to never had a truly horrible manager. I just want to go my own way and have my own small business. If only it were so easy.

kilroy123 8y ago
You're telling me! Software engineer != Entrepreneur It's been a brutal run so far. I'm failing at it and it's hard not to tie your self-esteem and self worth to it all.

austincheney 8y ago

All the people that I wanted to be like, growing up as a developer, were people who seemed more focused on their programming hobby than their programming job. Here is the take away that I noticed about those people and have attempted to apply to myself: * Extremely focused on product quality and defensive code * Maintenance focused more than feature focused * Excellent with documentation * Indirectly focused on self-promotion by writing good books or producing beneficial tools * Never directly focused on self-promotion It is so easy to get bogged down with bloated, dependency heavy, framework bullshit at work that product quality is distantly lost. When writing important software as a hobby you don't have to conform to a lowest common denominator for acceptance by new hires.

adregan 8y ago
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.

sixstringtheory 8y ago

I had a crisis similar to what you describe about a year and a half ago. I still wrestle with whether or not I want to stay in this industry. Client acquisition has been its own brutal process, although working remotely no doubt adds to the difficulty. I’m lucky enough to travel with my wife, who has a good job in a different industry, which has helped buffer the difficulty in landing consistent remote work. I definitely don’t regret my decision because I’m happy to busy myself with hobby or non-tech work, but just make sure you’re aware of the risks. I wish you and anyone considering the same the best of luck!

hef19898 8y ago

Isn't it incredible how much one bad manager can make you think about leaving a domain you genuily like and are really good at? Best thing to do, from my experience, is to take some time off (if you can afford to) and get your head clear. Distance really helps.