Errors are not failures
blog.charliemeyer.co
blog.charliemeyer.co
That's fair, of course, and reading error messages can be very hard sometimes even for the best of us. Still, I think there is a psychological hurdle to understand errors as a process, not as a roadblock.
Programming is (among other things) the art of knowing how to speak to a computer and gow to interpret the things it says. That means everything that damn thing says gives you hints of how it "sees the world" and how you therefore need to describe things to it so it can execute them for you.
Then they act surprised when someone objects to any of this in pull request reviews and even more surprised when asked to do it properly and finally even more surprised when asked why they didn’t reach out for help. They always seem genuinely like they’ve never heard of the idea of help before despite being repeatedly asked to ask for help when they aren’t sure.
Really hard to say what this is but this level of hand holding required feels like a failure in a part of the interview process.
It's also hard to know exactly what "not being sure" is. Does that mean 15 minutes without progress? An hour? Half a day? What if I'm still making progress, but slower than usual? Seniors love to say "ask for help if you're not sure" but I've never heard anyone properly defining what "not sure" is supposed to be. When I ask for clarification, some of the time people look at me like I'm an alien. I understand that managing people is hard, but I also find it hard to be managed when expectations aren't clear and are mostly a reflection of "I wish things were better".
You are right - it's very easy to feel like things are normal if you think you are making progress or eventually complete the task. If the task could have been done with 10% of the time/effort, you may not even know.
Something I found works for me is trying to be transparent about what is going on in general. Like I'll over share a bit of what I am working on and how I am thinking about it. If I am really fucked up in my thinking, usually someone says something.
When I first started programming for actual money (an embarrassing number of years ago now) I remember the old guy mentoring me wouldn’t let me use a debugger. “You have to think through the code, the debugger is the last resort”. I didn’t agree, it just looked like masochism and bravado from someone who hadn’t had good tools so I should suffer too.
Now that I’m the old guy, I recognise the wisdom. Stepping back, thinking through the problem, and you can write all that code without the inefficiency “run” “error” “modify”.
Or maybe that’s just how us old guys think.
These days, I work on buzzwords like kubernetes, microservices and Go and I likely couldn't use a debugger for customer issues even if I wanted to. Instead, I rely on a mix of intuition, logs and sometimes blind luck. I wonder if I've accidentally ended up in a domain that isn't that difficult. Or perhaps my luck will run out and I'm going to hit a debugging brick wall some day in the future.
Easy problems / bugs require next to no hypothesis. You just see the error, backtrace or whatever and can go fix it.
But harder bugs and system bugs usually require information gathering and analysis of that information to figure out and form a good hypothesis. To do that, just like your mentor said, you need good knowledge of the code and good understanding of what the information is telling you and what that can suggest or rule out.
But this is all very different from “just” thinking through the code. If anything, my cognitive capacity has declined significantly with age. I depend heavily on tools to shorten the paths I have to think through in the first place. And tests (if you’re doing TDD anyway) are just a more efficient “run, error, modify” after all.
Having said that, I am quite keen to not learn from my experoence and I keep doing a thing I know doesnt work.
Sometimes you have to slow down to go faster.
A few times I have insisted on escalating every error in order to improve a noisy program. A client that breaks connection with us isn't an error, that's a notice. An upstream database that breaks connection with us so we can't process a query, that's an error. It's not fun but it gets better.
However, there is something to be said about accepting one's mistakes and not wasting time dwelling on them; and instead looking at the bigger picture, or at least at something more constructive. Life in general is a lot better once we learn to do that.
For the new software engineers that are too frustrated by their constant mistakes, I want to say a few things:
1. You cannot become an experienced software engineer without getting the experience.
2. You cannot become skilled in a programming language or any tech without spending the time to become skilled at it.
3. You were not born entitled to be a good software engineer. As a baby, you were objectively awful in the discipline. As you have progressed to your current level of expertise in software, so will you continue to progress.
4. It is best to not overthink software engineering and just try to do it well.
5. You are the only judge of your failures and successes in life. No one else in the world decides how you feel about them. It is your prerogative to forgive your own mistakes - big and small (like a coding error) - if you so wish.
6. All new software engineers make many mistakes.
7. Likewise, all experts in every field regularly make mistakes. Just the kind of mistakes are different. But it is the human condition to make mistakes.
8. You will probably get to where you're going in the end if you persevere.
"file not found" and "permission denied" illustrate shortcomings? how else could you get this information if not from an error message?
If a software engineer sees their software crash because files or permissions are missing, I think that is definitely an opportunity to improve their skills and handle such cases in their code.
And I want to be clear about this - I do not blame, nor judge, nor is it my place or predisposition to judge people for errors in their code. But I think for those who judge themselves as many software engineers do, it is important to make peace with making mistakes.
There are many different kinds of errors, but they can be roughly divided into two categories: business errors and technical errors.
Business errors are not really an errors, but rather alternative business outcomes. Paraphrasing Kellyanne Conway: business errors are alternative results;) Something like Saga pattern or ACID transactions can be used to handle this kind of errors.
Technical errors are also a huge category, the most important properties are whether they can be reported to the end-user, or they make sense to developers only. Also are they retriable or not.
Lastly, some programming languages/runtimes/VMs reporting lots of ignorable errors, e.g. look at the log of any JVM application, you will see lots of exceptions, same in the browser's JS console. Even in Erlang/Elixir logs you will see supervisor errors, etc. IMO it make sense to expect clean logs in case of normally functioning application, but that's not the case for most development environments today.