Or you can do an apparently shocking thing to programmers: learn from others’ mistakes. Of course this would require admitting other people aren’t complete idiots and may actually know a thing or two.
I studied Film. Film similar to programming is a field where there is so much to learn and every project might be completely new and follow it's own rules and circumstances.
I had many collegues in unversity that had to shoot themselves into the foot. A normal part of learning. But as we were always working together everybody had the chance to see the others doing so.
Now there were some people who saw others shoot themselves in the foot in a particular way, only to go and do the same thing on their own project. Don't be that type of person. Be the person who observes others shoot themselves into their foot and wonder how you could prevent yourself from doing that in the future (and accept that for some things you can't).
Software engineering is very similar. Sure maybe you are the type of person who can't grok a footgun unless they got shot by it. But you can try not to be that type of person. Making mistakes is important. But make them at home or in toy projects, don't make them in a decade long effort by a ten people team with the data of million people. And if you are in such a project it is part of your job to learn from other similar projects and the ways they shot themselves into the foot.
Film (production) grad here as well. A good film school program is a space where teams of people get to make all their mistakes and figure out what they're about while making horrendously flawed pieces. Everyone exits with a slightly different baggage of experience.
I would add one thought here - it's not just about seeing others make mistakes, or about making the mistakes yourself. It's also about seeing how mistakes can be made across bigger teams or time-frames. Well-intended innocent creative choices at one point in the process can cause serious trouble later. Or two independent choices can create unforeseen problems. That's the sort of experience that's least visible, and that's what experienced mentors can provide.
So, I would argue that it's best to have a healthy mix - you want to see others fail, you want to fail yourself, but then you also want to have mentorship by others who have made these failures themselves. Seeing someone else make a mistake and then making that same mistake yourself can be a very valuable and humbling experience.
I do agree with you that the profession doesn’t lack its fair share of big egos and self taught arrogant geniuses.
But there is a difficult equilibrium to find between this and the other side of the coin which is the cargo cult of inherited best practices and over engineering.
Most programmers (including sometimes myself) have a hard time choosing the right tool for the right job. But learning to pick the right tool is hard.
Even learning this from others is hard : I’ve happily learned from a lot of specialists how to use a specific tool in depth, but I can count on one hand the number of people who suggested me a better tool for the task.
Yeah, that was my reaction to the article too: of course learning from your own mistakes leaves the most lasting impression, but you don't necessarily have to make all the mistakes yourself (e.g. you don't have to get in a car crash first to learn to drive safely).
Because you probably can extrapolate your experience from learning how to ride a bike, or to walk, so you don‘t need to crash a car. Probably everyone here has the experience, that the faster things collide with you, the more it hurts.
That's the issue with a lot of educational ressource, they don't tell about the problems that are to be solved. For OOP for example, I would an iteratively built ressource that present a problem then a first solution, and the new problems that it introduces, and so on.
I think that is the most obvious optimization of your time.
However I also think that most people need to experience the pain and frustration of hitting themselves with their own decisions a number of times, until they develop enough humbleness to see the benefits of using other's experience instead.
Nothing drive the point home than emotional pain. Of course, if it can be avoided, do learn from those who made mistakes, but sometime the best teacher is doing it yourself.
Let's celebrate that civil engineering isn't as arrogant as software engineering then. If a bridge collapses all the world learns from it. If Microsoft fucks up their Roken Authorization it is just another software error that cannot be helped.
I’m pretty sure civil engineering is based on mostly immutable knowledge of the physics laws which allows best practices no to evolve every year or that when they evolve, a mandatory training is required for everyone.
I’m also pretty sure that students in civil engineering are making virtual bridges collapse every single day.
It’s also true in other engineering branches : we have barely the same planes design since decades and that’s for good reason.
It’s not really something you can do when rules and best practices are going left and right every couple of months.
And don’t get me wrong I’m convinced that the peak of program engineering is in the past. But the industry keep forcing new things to developers.
What I refer to here is the fact that every early bridge collapse has informed the practise of the whole field after¹.
Meanwhile in programming you will literally have someone hash their passwords using md5 in 2023.
Maybe the difference is liability and possibly ending up in jail when things break. Software error has become a common excuse these days. If your companies enourmous unethical fuckup is exposed, just blame it on software error. Everybody understands: software errors happen and there is nothing we can do to prevent them from happening.
Only this is not true. We know how to test code. We know about formally verified code. In safety critical domains (aviation, automotive, industrial, banking, ...) we have been doing this forever.
I am not saying that every garden shed should have to follow the same rules as an interstate bridge, but maybe if our webservices fail spectacularly on a regular fashion maybe we should look towards software engineering practises that prevent things from failing that often?
¹ After that most bridge collapses have been due to organisational failures, like a lack of maintenance or a lack of oversight or enforcement of the established rules
By three methods we may learn wisdom: First, by reflection, which is noblest;
Second, by imitation, which is easiest; and third by experience, which is the
bitterest.
This doesn’t work when most people are self teaching.
It’s the job (and value) of a teacher to help you understand not only how but why we do like this.
Since we are more or less thrown is this beautiful "life-long learning" career without professional teachers, it’s way harder to understand the why without exceptionally great mentors. And that’s my pet theory that this is at the roots of cargo cults.
So what you are saying is that the solution is to make software engineering a profession that requires an actual education and certification?
Before civil engineering became a profession all kinds of people would build bridges and all kind of bridges would collapse. The solution wasn't to accept that bridges collapse, the solution was to not allow just anybody to build a bridge and to create standards that bridges had to adhere to.
Also, as a self thought programmer that is regularily shocked of what he finds in the field, done by supposed professionals: Being self thought has nothing to do with it. Because I can also read on someone's experiences and mind set. Every self thought programmer will read books on programming made by people who program. Even self thought programmers will avoid goto atatements like the pest even if they don't know the original reason for that rule.
The problem in software engineering is one of culture. We program shit and move on. If it breaks it is not our fault. Very few people feel ownership and/or responsibility for the code. Granted: Very few companies are willing to pay the money needed to allow for such a process, except if they are in a field where it is required by law (automotive, aviation, ...)
What we need is a clearer liability structure for software errors. If a companies software is investigated after privacy leaks and they are on the hook for each individuals data that they mistreated if the software is not up to standard companies will think twice to cheap out on software engineering. If software engineers are on the hook if a company gave them everything needed to make a safe product and they didn't, they are on the hook.
I don't say everything needs to follow that level/standard, but as of now a software error is treated like a unavoidable act of gods will that nobody could have foreseen or prevented.
even with self-teaching, you look up forums/tutorials/etc. they aren't so direct, but many past mistakes are wrapped up in these places of advice. i imagine there would be at least 9 past mistakes by others incorporated into the lessons and advice (and comments) of the topics, for each mistake you make yourself.
