Input from devs out in the world

I know many of our fellow forum members are developers more experienced than myself, and I'd appreciate feedback from any developers as I reflect on some experiences.

I've recently completed a second internship. Both internships left me with positive reviews, but also with some feedback about how to improve before I enter the work force next year.

One big thing was: fail, and fail fast
And that sorta hit home a bit. It made me realize I am terrible at admitting failure and pushing forward from it.

At a developer conference I went to this summer, one speaker spoke at length about embracing failure rather than running from it, which, of course, is easier said than done.
They said failure is completely inevitable, and to stop trying to hide from it.

Has anyone else struggled with that? How did you begin to improve that?
There's no real "This is how to get over it" guide, I'm really just wondering how others might have encountered this issue, either with themselves or people they've met in the field.

Failure is so heavily pushed as something to avoid at all costs today, so embracing it sounds odd every time I say it to myself.

Maybe some others can provide some reflections here, I'd appreciate any input you all might have! Maybe it'll help someone else as well who maybe doesn't want to reach out or speak about it.
Accepting the inevitability of mistakes is different from embracing them.
Fail-fast is not about resigning oneself to failure. It's about designing software so that any mistakes that may have been made during development are evident as soon as possible, when they're cheap and easy to fix.
The compiler rejecting a program is not failure. Failure is the program crashing so hard on the client's system that data is lost. Failure should be avoided, and fail-fast is a method to avoid it.
Perhaps I worded it poorly, but I see your point.

I think I was learning more towards failure in terms of hitting hard stumbling blocks and not pressing forward to get past them. Knowing I will, at some point, hit a road block and be unable to move forward simply on my own (or at least without spending a lot of time on my own). Fear of being labelled a failure for not being able to solve a problem, as petty as it may sound.

Though I like the phrasing
Accepting the inevitability of mistakes
more than
embrace
. Embrace may have been a poor word choice.
Fear of being labelled a failure for not being able to solve a problem, as petty as it may sound.

It's a common fear, but it's also completely unwarranted. The real problem with failure is hitting a road block and not asking for help, or pushing through with a poor design instead of changing it. We've fired people for that. On the other hand, if you have a bug and point it out, everyone will work hard to help you fix it.

I think the fear of failure and fear of asking for help comes from our school days. In school, you're expected to do all your work by yourself. Every failure lowers your grade. This mentality tends to come with us as we enter the workforce, but it's completely out of place there.

For something concrete, try this: if you get stuck on a programming problem for more than 30 minutes, seek out help.

Also, "fail and fail fast" is about checking for error conditions. School assignments are usually about "given this input, generate this output." In the real world, that's just the starting point. You also have to check for every error. I'd say that only about a quarter of our code is the "straight-line sunny day" functionality. The rest is error handling.
I think the fear of failure and fear of asking for help comes from our school days.

I'd have to completely agree. I'm just now entering my final year of school, coming back in from my internships and realizing school pushed me the entire time to work on my own and not seek help from my peers, quite contrary to how the companies I interned with pushed us to work. Errors/mistakes/road blocks were harshly punished in school, in work they were pointed out, but everyone was willing to help fix them and help make sure everyone understood how to avoid those in the future.

I know I'll go into my final year with an improved attitude on it, though it may be difficult to fight it at first. There are only two real classes that push for collaborative development - Software Engineering and my 2-semester capstone design class. I know that even getting a 5-second suggestion/reminder/hint when I get stuck is immensely helpful. Graphics? Work on my own. Algorithms? Work on my own (professor was pretty harsh on this one). Operating Systems had us in 2-person teams, but my goodness I'd hope much larger teams work on OSes.
Everyone wound up working in teams outside of class, but would also wind up thrashing code/refactor/etc to hide that.

I can recall many instructors telling me to avoid asking too many questions, and that stuck with me. Many questions were met with "...you can figure it out."
But when I was interning this summer, my fellow team members had no problem answering my questions and spending time to help me fix something/make sure I really understood what was going on. They never looked down on me for reaching out and asking for help. There was one senior software engineer on our team who gave me more insight in 2 months than I got from a year of schooling.

They certainly were right when they said internship experience is absolutely invaluable. I wouldn't have had the opportunity to learn that fear was unwarranted, and also that it's incredibly common.

I do wish my schooling hadn't pressed that so hard, as it's so deeply ingrained now.

I know there's a difference between asking a question that I should be able to easily answer myself with some research and a question that would warrant seeking help for. So of course I'll try to research an answer the best I can before reaching out, but no one loves banging their head on their keyboard over something they're stuck on too much.
Topic archived. No new replies allowed.