I love the simple software-centric approach to analyzing this survey and categorizing the answers.
There's one thing I'm sure was mentioned a lot by 17.1% of the participants, but it's one thing I'd like to stress:
Find a good mentor!
I've been teaching my son programming steadily for a few years now, and every so often he likes to take what he just learned, go and revisit some old programs he wrote or read from before he understood the new concept, and understand it better and often improve on it a lot (even rewriting it sometimes), and then he comes back to me very excitedly telling me how the new concept I taught him greatly improved the thing he did.
He's already writing code better than I did when I was a decade older than him, easily grasping new concepts like linked lists, garbage collection, pointers, and Lua coroutines and so on. When I was his age, I was still struggling to understand arrays in QBasic, had nobody to mentor and guide and teach me, and was generally pretty lost. Having a mentor who can guide you carefully and at your pace is an incredibly powerful shortcut.
At my old Hackerspace, one of those high school robotics teams came to us for some help. The kid who was doing coding could really have used that advice. He confessed to me that he didn't have time to read through all of the controller framework code and understand it completely. We were under coding marathon conditions at that point, so he wasn't far off with that. One of the motors they were using was pretty big, though. Plenty big enough to seriously hurt someone. So I urged him to at least set breakpoints in all of his stubs, and step through those in the development environment at a minimum. He was pretty dismissive about checking his work. Downright smarmy, actually.
Sure enough, something goes wrong, and the metal body of this robot ends up spinning wildly, right in the middle of the team huddled around it, sending parts flying everywhere. Miraculously, no one was hurt. Did that kid learn anything? Nope. He still knew it all.
That reminds me of me. I was overconfident in my abilities so I didn't take the advice of people who were trying to guide and help me. But looking back, I think a big part of what played into that overconfidence was not seeing that I actually could do the cool things I saw other people doing, because I had no one to show me how. So I was satisfied with doing slightly cool things and convincing myself it was amazing. I think a good mentor can show you a clear path from A to Z and get you excited about the fact that you actually can do B, you just have to start with A, then go to B, etc. That's one of the things I've been doing with my son, is trying to show him a cool thing that seems too advanced for him, and show him that it's only a small step up from where he is, and that after a simple 30 minute lesson that he fully understands, suddenly he can actually do the thing he thought was impossible! He just went from A to B in 30 minutes! Enough times of doing that and you're already half way to Z and it doesn't seem so impossible, so you stop being satisfied with letting yourself thinking B is actually Z. I'm probably not making much sense, but I hope the point is coming across at least a little.
That's one of the things I've been doing with my son, is trying to show him a cool thing that seems too advanced for him, and show him that it's only a small step up from where he is
Right on! One of the most valuable skills I've learned over the past several years, is how to decompose your projects into small pieces, then decompose those things into even smaller bits and keep going until the pieces seem downright stupid. That last part is the key. You have to keep going until you'd feel insulted if someone asked if you could do those things. This sounds bad, but it's actually a very powerful mental tool.
Let's say you want to build an MMO. That's a really huge, complex chunk of work. So let's just take a piece of that, let's say the networking part. That's still really huge, so let's just take a piece of that, like the part that synchronizes the client's ship position. That's still quite big, so let's just make something that can send some kind of data between some clients and a server. Well, it turns out there are a bunch of tutorials online for building a Websockets chat server, so let's just start with going through one of those.
Then, when you can send/receive data, write a game loop simulation of an Asteroids ship, and build it into the server. Then, for a client, forget about networking altogether and go through a Javascript Asteroids tutorial. Next, sync those two in the stupidest way possible. Then, when that's working, make your sync just a bit smarter. Rinse and repeat. This is actually how I started building my game server.
(You can see a sort of reverse chronological order of this process here:
What’s the context here? You mentioned lua, is it love2d (gfx or game oriented)? What’s a C to D example of what you’re talking about? Interested because I have an almost six year old, time to get going on this sort of thing myself!
We've been using Love2d and PICO-8, but he's a teenager. I too tried to teach him programming at an early age and then every few years after that, but none of it clicked until recent years.
The need of mentoring must be completely voluntary. I was hired to be a team senior of developers who didn’t think they needed a mentor and it didn’t work out so well.
People actively seeking a mentor are likely willing to consider the advice and tough criticism they get as points to self-reflect upon, because they want to improve. They want to become faster stronger developers. As common as that might sound I have found intentional yearning for self-improvement to be rare or severely misunderstood among junior developers in the corporate world. More common than self improvement is interest in specific technology stacks of the moment and persuit of near instant gratification.
EDIT
Actually, I can remember observing this behavior once as a junior developer. When I started learning JavaScript 12 years ago the real big deal then was Java. Compared to me at the time everybody seemed incredibly experienced and talented, but most of the developers were negligent to the point of horrid incompetence at the frontend skills even though this was a big brand web business and 90% of their efforts generated frontend code.
There were a few Java developers who did have a solid understanding of the frontend code, but they intentionally didn’t advertise this. I had to actively observe for it. After badgering some of these people it was clear they were willing to provide mentoring if I asked for it and worked my ass off to chase it.
What I learned the hard way is the people who made the best developers had a secondary skill they actively thought about more than their primary skill and used that to reinforce their primary skill. At first it was Java developers who had a solid grasp of things like CSS, but I also saw it in others who were working out product management skills or business pricing logic more related to finance than programming. These people also tended to make strong mentors. The people focused on only their primary skills weren’t as capable and didn’t seek mentoring themselves or have much to offer other junior developers.
On that topic, if you are the most senior person on the team and the other members don't seem like they want mentoring, my biggest piece of advice is to wait. Sometimes it feels like you are waiting forever (and with some people you will be). Mentoring is as much about trust as it is about passing over knowledge. You can imagine the people you will potentially mentor as wild animals. Even if you have gobs of yummy food on hand, they won't be ready to take it from you at first. The trick is to stand still, keep your calm and keep offering small little treats. Eventually one or two of them will come by and take a nibble. Don't pounce on them. Just stay calm and keep offering treats. Eventually some of them will come to trust you well enough to eat a whole meal from you. Some never will. That's just the way it is.
Similarly, don't assume you aren't already someones mentor. Mentorship isn't always explicit. I'm always open to helping solve problems, and giving my (admittedly biased) opinions on things. Came as a bit of a surprise when one of my peers wrote "I don't think he knows this, but I consider him to be my mentor" on my 360 review. I definitely don't need recognition for anything, I'm always going to try to help people, but it was an important lesson for me. That realization has helped me understand the things I'm doing are influencing people -- both good and bad -- and has set me in a direction of identifying and eliminating my negative influences.
In front end development trust is universally near absent. People are wanting instant gratification and there is huge peer pressure to concede that a tool or framework will solve all your problems for you. Invented here syndrome is the name of the game. They don’t trust themselves or each other. It really feels that for most frontend developers it really is all about tools and trends until they spinoff into another career path or promote out.
I'm not sure about typical front end development culture (the front end devs we have on our team are really very good), but I have been very surprised about how this generation of programmers in general choose to trust people and code. To be fair, it might just be some of the people I've met, but as an old guy, it seems to be more prevalent than I've ever seen before. I find that younger devs are prone to trusting code written by people they've never met before. If it's popular on the internet, it seems that it must be good. On the other hand, they seem to be very cautious about code they get from their colleagues. As you say, invented here syndrome. It seems like if the code was written by someone they know, then it can't be any good.
But I think a lot of that is a lack of confidence and experience. It's hard to talk about this without sounding like a gigantic ass because no matter how I put this, I can't find a way to express how much I really respect other developers. However, I've noticed that there seems to be a big reluctance for actually reading and appreciating the code in the tools people use -- almost as if there is some magic seal on the code and despite it being open source, we are not worthy to gaze upon the code. I think there is a fairly large amount of hero worship going on and a kind of herd mentality. To question the laws that were handed down from on high is blasphemous (almost literally). It is to the point where many people feel that they are transgressing badly if they even deviate from the "community approved" coding standards. Thank god for auto-reformatting tools is all I can say!
When these same people see their colleagues, they realise that it's just some other goofball like themselves. Their colleagues are struggling, making mistakes, rewriting, grinding away. So I think there is a kind of group impostor syndrome going on where they think, "Well, that guy isn't that much better than me and I suck!" What they don't realise is that their heroes in the FANG companies and their nameless horde of community members are just goofballs too -- struggling, making mistakes, grinding away.
I think as well, we often see projects and people fall from grace. Some project grinds to a halt, or the horrible problems it's had from the start become more obvious to the horde. And then all of a sudden it's, "That guy is a joke. Only morons would use that framework. All the cool people have moved over to <some other equally flawed thing>". But again, I think it's just part and parcel of a lack of experience and confidence. Most young devs are secretly, desperately hoping that somebody out there knows "how to do it right". They get disillusioned quickly when they discover that their heroes don't know how to do it right.
And of course, nobody does ;-) But that's a hard message to sell.
As a side story to your wonderful comment I had a colleague recommend I use a different IDE at work because their favorite code beautification tool was only available in one editor at the time. They didn't realize I am a contributor on the project they were promoting or that one of the code beautifiers in that project was mine. The team on this tool were actively working on diversifying to various IDEs but just hadn't gotten there quite yet. That was an awkward moment.
JS is something like 23 years old, so it cant be blamed on trends or youth. I think the problem is that nobody tests dependencies. There is a misguided belief that everything is community tested, wonderful, and that this community stamp of approval is superior to any decision a person could make. To me this sounds stupid and criminally negligent, but I have heard this very reasoning more than many times.
The reinvention of JS for use in serious projects is only about 10 years old however. A lot of these folks were early career and using a language that's not been historically strict.
> The need of mentoring must be completely voluntary.
Good point, you can't force it on someone. What you can do however is explain to new programmers how valuable it is, this is not innately understood. The years where I had someone mentor me were the years where I made immense progress. Even though neither of us even considered it mentoring at the moment.
Please stop dropping this empty-yet-well-meaning line - you're not the only one in this field who does this, either. I understand that it's not with ill intentions, but it's a feel-good line that people with experience like to drop on the internet as a catch-all piece of advice for how to develop software competency. The mentorship culture doesn't permeate nearly as strong as many of you think. Smiling and going "find a good mentor!" hides the complexity of the task and is disingenuous - it's a task that is limited by physical geography, electronic geography (the online communities one frequents), workplace culture (for the employed), and sociability of all parties involved, and a task that changes based on whether or not the recipient of this line is employed or in higher education at the undergraduate level. It can even be limited or change based on the mentor-seeker's current tech stack.
I'd venture to say that stunningly few people actually actively thought "I think I'll go and ask someone to mentor me" and then went and did it because of all the reasons you say and more.
I would imagine most mentorship is of the incidental kind that just happens as you work with colleagues and some of them teach you things that take you to places you wouldn't necessarily have gotten to on your own. You may in turn do the same for others without realising it.
Definitely working alongside good developers naturally benefits you greatly.
"Good" being the key word. Most professors I had in my day were probably masters of the material, but their droned explanations bored me to death and were overly theoretical.
Asking for help was a sure way to be mocked by your fellow students, who for some reason lived by the idea that it's okay to mock people for not knowing something they do know.
And then lab professors saying it's not their job to explain things, just google it. I was literally told several times by the lab professors that "we're just teaching you how to effectively google things".
I wonder if that contributed to my hating bad documentation and guides.
Tastes vary. Not about being mocked, that sucks, but about what's important and interesting. When I was in college I borrowed algorithms textbooks from a CS student to study for fun but never took a single CS class because I didn't want to do the "boring" stuff she was doing for class like writing Telnet clients and kernel modules and implementing parts of the network stack. I loved the books that concentrated on theory and yadda-yaddaed how it might be applied in the real world. Ten years later my tastes were reversed; I was sick of math but really curious about nuts and bolts. So don't assume people are put off by focusing on theory and dismissing everything else as "Googleable"! For some folks it's exactly what they're looking for.
Find a good mentor and listen. Don't have a chip on your shoulder. Don't be afraid to try a different approach. But sometimes a mentor will explicitly warn you, and it's almost funny when the person says "fuck that I'm going the route you warned me about"
I might not know everything by any means and generally provide a couple potential ideas, but 6 months later and they come and say "yeah you were right"
From personal experience, some people (i.e. me) are too pig headed to learn from other people. Sometimes it feels like a step down to take on a mentor. Sometimes it feels like the available mentors are all so far behind you that there is no point. But there is a real danger of getting isolated in a local maxima and not being able to jump across to somewhere better. Sometimes you have to lower yourself in order to go higher.
I once had a good manager who explained to me that perspective is like looking at a room through a small window. You can only see part of the room. Other people are looking through other windows, and likewise can only see a small part of the room. In order to see the whole room you need to see what the other people see. You have to go where they are and look through their window. It's the only way to piece together the whole picture. Even if you have the best window and the best vantage point, it's still better to give it up for a while and take a look at the other vantage points.
So, it doesn't really matter who you pick as a mentor, except it should probably be someone who sees the world differently than you do. And it will be really, really annoying for a while (maybe a long while) ;-)
Finding a mentor is really hard. I've been trying to find a mentor since a year now or more. Either I get ignored, and if people agree they just can't spare time then I also don't feel right to nag them with questions.
> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. https://wikiquote.org/wiki/Edsger_W._Dijkstra
There's one thing I'm sure was mentioned a lot by 17.1% of the participants, but it's one thing I'd like to stress:
Find a good mentor!
I've been teaching my son programming steadily for a few years now, and every so often he likes to take what he just learned, go and revisit some old programs he wrote or read from before he understood the new concept, and understand it better and often improve on it a lot (even rewriting it sometimes), and then he comes back to me very excitedly telling me how the new concept I taught him greatly improved the thing he did.
He's already writing code better than I did when I was a decade older than him, easily grasping new concepts like linked lists, garbage collection, pointers, and Lua coroutines and so on. When I was his age, I was still struggling to understand arrays in QBasic, had nobody to mentor and guide and teach me, and was generally pretty lost. Having a mentor who can guide you carefully and at your pace is an incredibly powerful shortcut.