Hacker News Reader

I haven't looked at your past blogs, but it certainly sounds like you are making perfection the enemy of good. Your blogs don't have to be perfect, it just needs to be better than the current state, while not causing unanticipated regressions. Your blogs do not have to be prescriptive either. All you have to say is: I've tried x, y, and z, and it turned out better than a, b, and c in this-and-that manner. Provide your argument, and let readers judge whether your advice applies to their situation.

That said, if you do not have actual data or experience to back up what you are preaching, I definitely welcome the call for caution. It is not useful to insist that "everyone should learn a certain skillset" unless you found those skills relevant in practice in some situation.

It sounds like you've been compiling an interesting collection of stories, ones that might be interesting to a lot of folks here.

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.

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.

I'm not sure if this is what you're hinting at, but parts of what you say are very good reasons why the whole "Learn to Code" movement is not going to take off (nevermind be successful).

It's not a "simple" matter of "just do this". The nuance, understanding and being able to think and reason abstractly is tucked deeply into the craft. Actually giving a damn goes a long way, and that's just the tip of the iceberg.

"Learn to Code" is very different from learning to become a good, reliable software engineer. The skillsets are very different.

I think alot of technical schools are optimizing for "Learning to Code" with modern frameworks used at work, leaving much to be desired if I want to hire a bootcamp graduates.

I'm experimenting with a system where students only learn the bare minimum and built up what they know by asking questions and working together as a team to build a product with the intention that another student will take over their product one day. This mimicks an engineer's workflow better: asking questions because documentation is lacking, working with other engineers, being receptive to feedback, writing code with the intention of somebody else taking over your code, etc.

It seems to work so far, the last batch of students did some really amazing work and built cool open source products that I use:

https://github.com/garageScript/c0d3-app/pulls?q=is%3Apr+is%...

https://github.com/garageScript/myProxy/pulls?q=is%3Apr+is%3...

Unfortunately, these students have a hard time finding jobs and so I'm currently getting stumped there.

It seems that the more I try to validate my theory, the more questions I have. All in all, my point is that it is very hard to apply the "sharing publicly by default" mindset to practice.

> I'm experimenting with a system where students only learn the bare minimum and built up what they know by asking questions and working together as a team to build a product with the intention that another student will take over their product one day. This mimicks an engineer's workflow better: asking questions because documentation is lacking, working with other engineers, being receptive to feedback, writing code with the intention of somebody else taking over your code, etc.

That's a great way to learn, since a lot of the day to day work does require working in ambiguous, not always well documented, situations.

> Unfortunately, these students have a hard time finding jobs and so I'm currently getting stumped there.

Keep in mind that finding a job and learning to be a good software engineer are somewhat orthogonal things. The former can be achieved by reading CS books and grinding Leetcode to pass the interview, but doesn't achieve the latter.

Some tech companies have non-traditional hiring pipelines nowadays, I know that Linkedin used to have one where they'd do more of a apprenticeship-style period where they'd often give full time offers to people in that program. That may be a better fit for your students than just going in through the usual tech interview process, which is mostly geared at traditional candidates.

Thank you for sharing that, actually.

What kind of problems have they encountered finding jobs?

I think you are suffering from perfectionism. You are in a healthy process of continuous improvement, keep discovering things that you could have done better. But there could be thousands of engineers out there that could have benefited from being more like the version of you yesterday.

The ones who wouldn't benefit from it would just move on to read material more suitable for their level. You don't need to worry about protecting them from making the same mistakes as you do.

I have two careers: senior software developer for one the largest employers in the US and military. When military people ask what is required to be a professional developer they are always absolutely astonished when I answer with: nothing. I tell them just pass the job interview. That’s horrible. That is completely not how to mentor people, but it is the most correct answer according to industry practice.

By nothing, I think you meant: Build listening skills, learn some coding foundations, ace the job interview.

With good listening skills people will like you and you'll be able to pick things up quickly. It will help with the job interview too.

By nothing I mean things people put on resumes in other professions: minimum required education, licenses, certifications, professional organization membership, internship, published research, continuing education hours, accomplishments, and so forth.

This sounds exactly like the thing to KEEP on blogging about. Those people you mentored would look up to you for advice. Having humility to post about being wrong and what you've learned since is huge.

Don't be afraid to blog about multiple options either. I think value in being a successful senior engineer is knowing what to do once you can start to visualize those multiple options.