Hacker News Reader

Comment by jfim | Hacker News Reader

Part of being a more senior engineer is to be able to admit that one was incorrect, learn a lesson, and move on. It's also a good lesson for more junior engineers that no one is infallible, and what matters more is how one reacts to being incorrect.

As for teaching people to become good software engineers, there's a technical part to it (eg. being able to structure a program, decompose problems into smaller problems, etc.) but some innate traits (curiosity, perseverance, humbleness) are also pretty important. I'd argue (without any data!) that the latter are just as important as the former.

View on HN

I think in OP's case they mentioned the nontrivial complication that admitting they did not teach someone well is admitting publically that some of your students are bad software engineers, which could affect them. It's not that they can't admit it to themselves, it's that they want to be tactful in announcing it from the rooftops.

I don't know what they taught them, but whom of us wasn't at some point a "bad software engineer"? That's a pretty normal point on a career path & I'm sure those with the aptitude of these students learned and improved afterwards.

I teach programming to absolute beginners (freshmen students in an art school taking intro to programming) & try to not worry too much about "proper software engineering" - I intentionally do stuff like copy paste the same code from one file to another & solve things in a "dumb"/verbose way if it's simpler conceptually (and thus easier to understand).

My goal is to get them from "afraid of the command line" to "can type some code into visual studio that can do something when you press run & then be able to expand on it further". Proper software engineering comes way later & will be taught by someone else (possibly by the students themselves once they realize the naive approach I showed them at first got them into a mess when they tried to develop a bigger program).

`Part of being a more senior engineer is to be able to admit that one was incorrect, learn a lesson, and move on.`

I agree. The more I know, the deeper I go to validate my assumptions, the harder it is to share.

No, I think you missed the lesson.

Making mistakes is part of being a great engineer. It's one of the ways you learn. You're afraid to put stuff online because you're afraid of putting something out there that's wrong, but as you already acknowledged, being wrong is part of the process.

Accept that some of the things you share will be wrong. But you won't know which ones until you share them and until someone corrects you. Handle that correction gracefully, and you will model exactly the behavior you're trying to teach.

> handle that correction gracefully

I’m interested in some ways to do this. For example, if it’s a blog post, do you go back and append these corrections? And how long do you have to do that? Should blog posts come with a shelf life?

Creating a new blog post and amending the old one to add a line at the top that says something like "Update 2020-05-15: New thoughts on the algorithmic complexity of spline reticulation" with a link to the update post works, and allows the reader to make up their mind on whether they agree with the previous post or the new one.

Reply on news.ycombinator.com