The most successful developers share more than they take
stackoverflow.blog
stackoverflow.blog
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.
You 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".
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.
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.
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?
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.