Make failing part of the process. Test Driven Development for example is failing first (all tests fail), then fixing it. Making prototypes is a way to fail early in the process, so when you start to make the real implementation you already tackled various mistakes. Write software in such a way that failures are expected, so that you handle them. Chaos Engineering is good example of this. Write clean code, have useful debug logging, etc. Once something fails, you'll be able to take care of it quickly as it is easy to diagnose and fix.
Even when beginners do all this, it will all be visible. But eventually you do these things with enough grace that it looks like you meant to do it.
Remember, nobody has ever written a perfect program, and you are unlikely to be the first. If a company cannot accept this, then get out!
never met a part of the stack I didn't like. sr. engineer at clique studios in chicago, perpetual creative hobbyist, bird friend, local gay agenda promoter. she/her. tips: https://ko-fi.com/carlymho
I think the other thing is to communicate early and often if things are going wrong, and to get comfortable asking others for help. A lot of folks learn to hide when they're struggling, but if you're working with a good team, they'll be able to adjust timelines and get you the help you need if you keep in touch about how you're doing, especially at the beginning of your career. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How to fail fast and properly.
New developers fail like an elephant in a porcelain cabinet. Experienced developer fail like ninjas.
Hi. Your point is interesting but I have a question. How I can fail properly if a company want all works well?
I'm going to finish my career in one year and I want to be a good developer. This community is awesome :)
Make failing part of the process. Test Driven Development for example is failing first (all tests fail), then fixing it. Making prototypes is a way to fail early in the process, so when you start to make the real implementation you already tackled various mistakes. Write software in such a way that failures are expected, so that you handle them. Chaos Engineering is good example of this. Write clean code, have useful debug logging, etc. Once something fails, you'll be able to take care of it quickly as it is easy to diagnose and fix.
Even when beginners do all this, it will all be visible. But eventually you do these things with enough grace that it looks like you meant to do it.
Remember, nobody has ever written a perfect program, and you are unlikely to be the first. If a company cannot accept this, then get out!
Ooo I understand. Thanks for your advice
I think the other thing is to communicate early and often if things are going wrong, and to get comfortable asking others for help. A lot of folks learn to hide when they're struggling, but if you're working with a good team, they'll be able to adjust timelines and get you the help you need if you keep in touch about how you're doing, especially at the beginning of your career. :)