When you define "great developer" as "top contributors on StackOverflow" (or the ones responsible for founding it), of course the overlap will be 100%. I understand that StackOverflow actively requires people to work on their platform for no compensation so they want to encourage the idea that contributing makes you a better developer, but this is even more of a puff piece than I expected.
All of the great developers (or at least magnitudes more competent/experienced than me) I met spend very little time on the internet writing comments/answers.
There are good developers that are out there helping others, but that usually doesn't require tremendous skill as most of the questions are simple and can mostly be resolved by looking at the documentation.
The hard stuff usually comes from doing things that were never done before or going deep inside a system. This usually doesn't apply to many people and is hard to share.
They do make mention of being actively engaged on SO, but this didn't at all read like a marketing piece for getting more SO users.
The key point seemed to be one I've seen echoed repeatedly elsewhere: a lot of good developers write and share a lot. It doesn't have to be Stack Overflow.
"Good" in this context I take to mean holistically good. Not just good on purely technical skills, but soft skills(particularly effective communication), organizationally dynamic, etc...
I read the article prior to seeing it shared here. My conclusion was that it's just sampling bias. Of course you will hear proportionally more of "great" developers if they share more about themselves. And of course those are the ones you'll invite to a podcast.
I don't even know what kind of statistical basis they want to put their claims on. A better title would be "the great developers that you hear from a lot share a lot".
They make an effort not to promote "share your knowledge on SO" strongly, but it's one of the two actionable thoughts any developer reading this would have. "I should write blog posts" or "I should answer questions on SO".
Wondering how much of this is convenience bias? If you want to make a podcast about great developers you’d probably start with the people you know, which is going to tend to be people with a substantial public presence.
Yeah some of the best, most creative and insightful developers I know have virtually no social media presence beyond git hub and a dormant twitter accounts
Well again I would like to point out that popularity and merit are not the same thing. One thing I have found is that because my comments, answers and open source software has not been popular, I have stopped attempting to share. However, I know that some of my least popular projects have had the most merit.
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.
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.
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.
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 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).
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:
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.
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.
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 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.
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.
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.
To the best of my knowledge, he shares in one way: a dump of his amazing code appears from time to time.
However, I have never read a comment, tweet, blog post, or mailing list post by him. They may exist and I have crossed paths with them. Or perhaps he's an incredibly helpful guy to work with. But that's not the foundation of his excellence.
Says a thing or two about communication and web scale medias. I kinda interpreted this notion when following mailing lists of some projects. People there speak few but deep. The complete opposite of the web 2.0 (microblog, tweet.. it's all high frequency low depth).
Good things require a good deal of patience and thinking ? I suppose that's what F.Bellard spends most of his day on.
That's an interesting example: the projects where he's had the greatest impact (QEMU, ffmpeg) are fairly normal open-source projects, with Fabrice participating with other people on mailing lists or bug trackers, not to mention successfully handing maintainership over to a larger community.
Where by "successful" is meant: the ones who get attention. In other words this is a tautological claim. Everyone else has already pointed this out, but as a non-self-promoting developer I have to add my bit.
Often the best programmers have zero self-promotion instinct, and this has nothing to do with not wanting to share. "Share" in this article means something like "publish", and that's both a different skill and a different desire.
Our gates are open, and we should adhere to that principle, but similar to free speech, we should make clear reasonable conduct. In other words, do not think your sharing is acceptable without some merit.
A good example of this was a recent 15 year old that wrote a blog post about lessons in being a developer that really should only have been written by someone with a minimum of five years of professional experience (and I’m being lenient, probably should be 7-8).
By principle we encourage the open gate, but If the growing trend is you are fresh out of college or a bootcamp graduate and write up a whole article on microservices and why or why not a business should use them, then our implicit guidelines are too ignorable.
The community should want sharing, but with integrity. We don’t want people sharing because of the concocted identity of a developer who must surely also write authoritative/instructor blog posts. This should be discouraged implicitly, and given the climate of lack of integrity based sharing (eg I worked 5 years, let me show you how to set up a scalable business model), then we must be more explicit until those behaviors change.
SO quality participation is in decline as it transformed itself into yet another online shredder of good will and "great developers" realize they're being exploited, cue content like this to try and goad them back.
Personally, that was something that truly believes in. Writing and putting them in public helps accelerate your personal development. As you write, you find yourself faced with a world of readers whom you have to be prepared to articulate your thoughts clearly, least not to lose the reader along the way. That clarity of thought is what deepen the roots of your domain knowledge. Personally, I feel you do not have to perfect the writing before it can start facing the world. Share as it comes and just makes sure you are better the next time around. Failure is part of the growth process! (:
Here's my blog sharing about some learnings I've had regarding architecture design patterns! Hope you will learn something from it! Do leave your comments as well, appreciate them!
One of the questions I always ask successful bloggers is: what motivated you to start?
The answer is always the same: I did it for myself.
This is an example of survivor bias; those who start a blog with the aim of attracting a following will lose motivation and grow impatient with the short term results. Successful bloggers have the personal confidence and passion for the topic to document and share stuff they think is cool.
I feel like a step is missing here. Is the survivor bias related to a similarly named logical error
(https://en.m.wikipedia.org/wiki/Survivorship_bias)? Or is it the “good” kind of bias in the sense that survivors are predisposed to have certain traits compared to non-survivors?
39 comments
[ 2.6 ms ] story [ 34.8 ms ] threadYou could share like in open source code contributions or in a blogpost in your own blog / domain
There are good developers that are out there helping others, but that usually doesn't require tremendous skill as most of the questions are simple and can mostly be resolved by looking at the documentation.
The hard stuff usually comes from doing things that were never done before or going deep inside a system. This usually doesn't apply to many people and is hard to share.
They do make mention of being actively engaged on SO, but this didn't at all read like a marketing piece for getting more SO users.
The key point seemed to be one I've seen echoed repeatedly elsewhere: a lot of good developers write and share a lot. It doesn't have to be Stack Overflow.
"Good" in this context I take to mean holistically good. Not just good on purely technical skills, but soft skills(particularly effective communication), organizationally dynamic, etc...
I don't even know what kind of statistical basis they want to put their claims on. A better title would be "the great developers that you hear from a lot share a lot".
They make an effort not to promote "share your knowledge on SO" strongly, but it's one of the two actionable thoughts any developer reading this would have. "I should write blog posts" or "I should answer questions on SO".
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.
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 agree. The more I know, the deeper I go to validate my assumptions, the harder it is to share.
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.
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?
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).
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.
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.
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.
What kind of problems have they encountered finding jobs?
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.
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.
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.
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.
To the best of my knowledge, he shares in one way: a dump of his amazing code appears from time to time.
However, I have never read a comment, tweet, blog post, or mailing list post by him. They may exist and I have crossed paths with them. Or perhaps he's an incredibly helpful guy to work with. But that's not the foundation of his excellence.
Good things require a good deal of patience and thinking ? I suppose that's what F.Bellard spends most of his day on.
What I meant is that from the outside, it appears like he's just focused on the work.
There are more junior than senior devs, there are more beginners than junior devs.
The more basic the stuff is you share, the more people can do something with it.
Often the best programmers have zero self-promotion instinct, and this has nothing to do with not wanting to share. "Share" in this article means something like "publish", and that's both a different skill and a different desire.
A good example of this was a recent 15 year old that wrote a blog post about lessons in being a developer that really should only have been written by someone with a minimum of five years of professional experience (and I’m being lenient, probably should be 7-8).
By principle we encourage the open gate, but If the growing trend is you are fresh out of college or a bootcamp graduate and write up a whole article on microservices and why or why not a business should use them, then our implicit guidelines are too ignorable.
The community should want sharing, but with integrity. We don’t want people sharing because of the concocted identity of a developer who must surely also write authoritative/instructor blog posts. This should be discouraged implicitly, and given the climate of lack of integrity based sharing (eg I worked 5 years, let me show you how to set up a scalable business model), then we must be more explicit until those behaviors change.
Open gate regardless.
Here's my blog sharing about some learnings I've had regarding architecture design patterns! Hope you will learn something from it! Do leave your comments as well, appreciate them!
https://blog.phuaxueyong.com/post/2020-05-03-3-more-cloud-de...
In relation to the post, I've also shared some of my personal thoughts on this:
https://blog.phuaxueyong.com/post/2020-05-14-first-half-of-m...
The answer is always the same: I did it for myself.
This is an example of survivor bias; those who start a blog with the aim of attracting a following will lose motivation and grow impatient with the short term results. Successful bloggers have the personal confidence and passion for the topic to document and share stuff they think is cool.
I feel like a step is missing here. Is the survivor bias related to a similarly named logical error (https://en.m.wikipedia.org/wiki/Survivorship_bias)? Or is it the “good” kind of bias in the sense that survivors are predisposed to have certain traits compared to non-survivors?