For Earth orbiting satellites using their own on-board propulsion with storable propellant, hardly anyone actually does these transfer orbit maneuver sequences in just two-burns. (edit: For example, for geosynchronous transfer orbit) the delta-V is almost always broken up into 4 to 6 maneuvers of decreasing size (to improve targeting accuracy at the end). The launch vehicle upper stage usually does the first burn to go from the low circular orbit to the elliptical transfer orbit.

For these onboard main engines, number of starts is not a concern.

Back when some geosynchronous satellites used solid motors there would be one huge maneuver at apogee to get nearly all the way to GEO (e.g. the Hughes/Boeing 376 spinners). The uncertainty in performance on these maneuvers was quite large so correction maneuvers were always planned afterwards.

Agree with all your points here. I find the old-fashioned BBS-style system at my company extremely useful. Needs email notifications (we have the option for immediate or batched). Being able to reply by email is a plus (ours does not have this)--helpful with getting people to use the forum instead of just email.

Same here. Also this one: 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

To what level this is true depends on the complexity of the system I suppose, and how accurate the requirements actually are.

I first read "direct pipeline to the wisdom of the ages" as referring to the internet. But now I am guessing it means that just like you don't have all relevant past information and analysis, neither did they.

Like other commenters have noted, the more experience you get and the more you learn to improve the design of your code right off the bat, the less debugging you should have to do. Hopefully then the coding part becomes just as fun as the debugging currently is for you -- a lot of satisfaction can come from coding something really well and having it work just as you expected the first time.

Have you ever coded for a project you were excited about? Where you could feel really good about delivering a quality, useful product? If possible, try and find that at your current job. If not, a new job may be the best route. Management and bureaucracy are great at squashing good vibes here.

Also, see if you can find some satisfaction in expanding your programming skills through reading and learning. Not sure your experience level here, but I would recommend that to anyone -- it has made a huge difference to me personally.

Pretty early in my career. I've held two jobs that both sound wildly better than any other option in the near area (small startups with tons of work vs. big businesses where nothing gets done).

I intend to spend no free time on my career outside of work. There are far too many other things in life I would prefer to work on and experience, hence why I wonder if this is the right field for me.

Sorry if I sound so negative, it's just how I've felt since first starting out in my field.