Deployed to production two days ago, errors still coming out and ALL of them have been my fault :(

I feel really shitty and I feel like I have no brain, maybe dev is not my career

Any advice to overcome this frustration? I really need to read your advices, guys :(

  • 8
    Shit happens buddy, recognise ur errors and move on.. and learn not to replicate these errors again. Cheers buddy.
  • 3
    I'd say don't focus on end goals & avoid using the word finish. Instead focus on process. When coding think how you are doing said thing.

    Generally if you are immersed in your process, you will produce good quality shit.
  • 1
    Realizing that a problem is just something you haven't had the pleasure of meeting yet and that your task is to understand it so you can help others and yourself in the future, should the problem arise again :)

    Oh and that, "that problem" needs to understand it ain't shit compared to you! Dominate it!

    Don't give up!

    ...Unless it's about hardcore "deep" C programs (FTP) (catching communication on port between zybo and a java simulator).. Then give up... xD..

    No seriously.. don't give in to it!

    Best of developing!
  • 3
    Many of the devs come from the bottom. Well you have stepped into a better devs so cheer up!
  • 3
    I know it's a cliché, but it's true -
    Persistent people begin their success where others end in failure.
    Rome wasn't built in one day and so on..

    Learn and move on, this feeling will pass soon, The most important thing imo is don't give up! and you can also take it as a mission to program your mindset for persistence & resilience.

    And also, get better at testing before deploying to production ; )
  • 0
    It's not your fault, it's a team problem.
  • 5
    Post mortem is important. How are you seeing the issues now that you didn't prior to pushing to production? Is there any change to the testing methodology that would prevent it in the future?

    When things like this happen, it gives you a really good opportunity to become a better developer, or tester at least. Don't sweat it.
  • 5
    First: accept that you will never catch all bugs before production, no one else ever has.
    Second: make sure you learn.

    For each error that slipped by write a use case, how could we have found this error in testing. (not necessarily a unit test but a description on how the error was triggered)

    Those use cases will be testing manuscripts for next release.

    Not only will they catch reappearance of the same errors but they probably also represent actions the users regularly do or are dependent on since they reported them and odds are that new error can be triggered and caught with the same tests.

    Over time you get a good library of use cases representing what needs to work.
  • 5
    Printed and pinned above my desk:
    Slow down
    Look again
  • 1
    Always do a test deploy. If you dont have a dedicated machine use a VM. Deploy on it and test it your self. 80% of the errors will be fixed on that stage. Next ask someone to test it for you. Then deploy. But always test your self dont expect someone to catch all bugs for you.

    Had cases with coworkers that where relying on the QA so much that pushed with syntax errors...
  • 4
    Write more, and better tests! There's no other answer.
  • 1
    @brainlessdev seems like very few people here have heard of TDD.

    Starting to write unit/functional tests can be difficult, especially for an existing project.

    Just begin by setting up the right library for your language, and write a test which only checks whether the entry point to your app/site is functioning. Then add a testing solution to your deployment chain so you only deploy healthy stuff.

    From there, do two things:

    1. Try to cover each new & rewritten feature with tests, so they become much more resilient.
    2. For every reported bug, write a failing test which proves that the bug exists. Then fix the bug by making the test pass. That way, you can make sure the same bug never comes back.
  • 0
    Why did you not roll back to non-broken build?
  • 1
    @bittersweet Yes! TDD is hard to get used to, but once you get the hang of it it really starts to flow.
    Also a great point about writing failing test cases that prove that a bug exists - some sort of after-the-fact TDD. It makes fixing bugs that much more satisfying. And most importantly, it ensures the bug won't happen again so easily in the future.
  • 0
    Shit happens, this is how you learn.. this is how I learn too
  • 2
    You are amazing, guys! I just got home from work and everything you wrote me made me smile. I actually wanted to cry on one comment :')

    Thanks for the support!! I will be a better dev !!
Add Comment