Hacker News Reader

Comment by kayodelycaon | Hacker News Reader

I can second this. I have learned infinitely more by doing and teaching than I ever have from being taught.

It might be a personality thing though. I’m a stubborn idiot who questions everything he’s taught. I don’t take advice. I listen to people stories. The why has always more important than the how.

I’ve been fortunate to have many teachers and mentors, but I didn’t seek any of them out and none of them guided me. They were people with the right perspective and I had asked them the right questions.

But the two best mentors in my life are my two best friends. All three of us are different and have different things to teach each other.

View on HN

I too learn better by myself.

But I think there's a difference between someone who 'teaches' you and someone who is at a high enough level to discuss ideas or issues with you.

For example, in my first job I 'learned' the most not from the senior engineers around me but from another new grad who was just as curious as me. We would discuss issues we're having, brainstorm solutions etc. It was not so much that I learned from him, but that I had another brain of similar competence that I could fling ideas at.

Not having such a person makes your job more difficult (as you might find yourself in a rabbit hole and desperately need someone else's perspective) and much less enjoyable.

Imagine not having a competent dev in your team to review your code.

It is not about "being taught".

But if you are the only technical person around, who is going to show you what a good or bad practice *in your specific field* is? That you won't find on Stack Overflow or by asking ChatGPT.

Being able to talk to an experienced mentor who knows the field you are working in is invaluable. Unlike learning some framework or design patters or what not, this information you won't find anywhere else.

You'd be surprised at how useful Stack Overflow and ChatGPT can be at helping to illuminate knowledge gaps.

I've found that one of the harder aspects of being unguided is figuring out the unknown unknowns.

You might stumble into a solution of sorts that mirrors a best practice but not know there's a "name" for that solution -- until you see it spelled out after googling around. That discovery can lead you down a rabbit hole where you gain fuller context.

Sure, having more experienced people around can help expedite that process in some cases, but then again you're limited by what that person has experienced. There's always some level you reach where you need to be curious enough in your explorations to seek out the next layer of knowledge in a self-directed manner, and the tools today are immensely better at supporting that process than 10-15 years ago.

I think the OP you are replying to points to "you don't know what you don't know". SO and ChatGPT can be useful, if you know what you are doing is fishy and ask for directions.

its the simple things

  fuzzing
  unittest
  scm
  code coverage

if youre programming without those, youre doing it wrong, and chatGPT isnt going to help

any more im missing?

What percent of developers do you think are actively using fuzzing? I would be shocked if more than 1%. Please do not read this as I do not think fuzzing is important! It is very important for system-level software.

I often include valgrind tests before Beta releases, as it is usually going to point out suspect areas needing inspection.

Fuzzing is only really useful for a very narrow range of analysis scenarios. If people understand threading properly: code should be able to take getting hammered, exiting gracefully, and cleanly get re-instantiated.

Also, banning hosts/accounts with an error-rate quota system is more common these days. =3

many languages gracefully handle errors, making those errors transparent to automated detection -- our crashes are now silent correctness failures

this trend in programming culture reduces our ability to do automated error detection!

you make a good point, and a good case for crash early and crash often -- with choice of erlang style recovery, or fuzzing style hard nosed correctness enforcement

Everyone hates hearing this one: Documentation, documentation, documentation. Programming is a social task. Therefore, everything else related to software development best practices branches off from that.

Reply on news.ycombinator.com