jgsteven

I wonder if cross-compiled Java to JavaScript or WASM would work here.

"None of the experts seem to agree on which of these is the culprit, so I figured that I (person with blog) should help."

In case you aren't aware of dynomight yet, there is a great backlog of posts to read.

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.