4 ms·

I have a hard time sharing. For the past 10 years, I had been working on a side project to answer this question: can I teach anyone how to become a good softwar

I have a hard time sharing. For the past 10 years, I had been working on a side project to answer this question: can I teach anyone how to become a good software engineer? 10 years ago, I thought everyone should learn a certain skillset and I blogged about them actively. Some of the articles made it to HN front page. It made me feel great. But every year as I grew as an engineer, my views of what mades a good engineer changed. I realized that I need to thoroughly test my views first before sharing publicly. So to test my changing views, I mentor a group of student learners every day after work and during weekends. I observe their progress throughout their interview process and then how they perform in the software engineering world. To this day, I still don't have a concrete answer, so I haven't blogged since. It's particularly painful when my ideas are wrong and the students I mentored turned out to be the kind of engineers I wouldn't want on my team. It's not their fault and blogging about my failures would single them out and I don't have the heart to do it. So over the past 10 years, I eventually stopped shied away from being "Public by default" until I have experimented enough to be sure.

jfim 6y ago
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.
- songzme 6y ago
  `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.
  - munificent 6y ago
    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.
    - yawboakye 6y ago
      > 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?
      - jfim 6y ago
        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.
- mattnewton 6y ago
  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.
  - ido 6y ago
    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).
troughway 6y ago
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.
- songzme 6y ago
  "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%3Aclosed https://github.com/garageScript/c0d3-app/pulls?q=is%3Apr+is%... https://github.com/garageScript/myProxy/pulls?q=is%3Apr+is%3Aclosed 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.
  - jfim 6y ago
    > 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.
jarjoura 6y ago
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.
austincheney 6y ago
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.
- songzme 6y ago
  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.
  - austincheney 6y ago
    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.
lopsidedBrain 6y ago
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.
dabei 6y ago
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.

jfim 6y ago

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.

songzme 6y ago
`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.
- munificent 6y ago
  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.
  - yawboakye 6y ago
    > 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?
    - jfim 6y ago
      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.
mattnewton 6y ago
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.
- ido 6y ago
  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).

troughway 6y ago

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.

songzme 6y ago
"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%3Aclosed https://github.com/garageScript/c0d3-app/pulls?q=is%3Apr+is%... https://github.com/garageScript/myProxy/pulls?q=is%3Apr+is%3Aclosed 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.
- jfim 6y ago
  > 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.

jarjoura 6y ago

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.

austincheney 6y ago

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.

songzme 6y ago
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.
- austincheney 6y ago
  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.

lopsidedBrain 6y ago

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.

dabei 6y ago

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.