Long term computer programmer, making my own library. American based. Far left politically. Promotes use of paper ballots. Follows news about environmental collapse, political corruption in my country, human rights, science and tech.

  • 34 Posts
  • 522 Comments
Joined 4 months ago
cake
Cake day: July 16th, 2025

help-circle






  • Dev mode is when developing by the programmers. Production means used by others.

    When I am working with a service, I want to know immediately when there is a problem.

    When I push my code to be used, the dev flag is off and the code does stuff as normal.

    For example: if I am making a payment service using a third party, I use sandbox and fake cc numbers. I want things to fail loudly on my computer so I can make things fail silently. And safely, when it’s used with real money. But I can only do that if I know there are issues. And only logging lets some bugs be unnoticed , particularly if a cluttered log. So being loud in development saves tears in production



  • Having read the other comments about the hard point is not the tech but the marketing.

    My suggestion is to not use internet to advertise at all, at least at first. Advertise by having beta testers use it for free in your community. And be a delivery person yourself. Be your own first and most frequent customer, ( as well as the delivery person). Have friends and relatives use it. Deliver to them.

    Always talk to businesses and users face to face, in your community.


  • All good points!

    Also, I’ve learned from others that how you crash depends on the environment, if running in dev, be different than if the thing is used by the public or in production.

    • In a script, dump too much data if dev, in production keep it terse but have relevant info and a link to the docs.
    • In a gui, webpage or app make the crash screen in dev be a thing of beauty that has the full stack trace, database info , and more. But in production only generate a polite message that is vague, with an error code. Push that error to a logging service with the code. And if this is not used by the public but by a company that paid for it, have a feedback button or live chat button, in the error message, to talk with tech support.
    • Backend services and libraries: if in dev mode crashes should be loud and definitely break things, while in production log silently and keep working.
    • And for any type of program: always back up data, and always use transactions to not have the database or files be in an incomplete state if an exception happens.

    formatting edit