Advice to new programmers

Find a good mentor!

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.

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.

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"

I may be petty but I've said "no fucking shit"

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.

I've been successful in my career but maybe I'm leaving something on the table?

> 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

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.

Ask if they tested it, if it worked. Let them use git history

Continue your work, help with the third time

I know you mentioned that, but often times asking that question makes people try again, or doublecheck what they are doing. Giving them the couple of hours gives them room to maneuver and _maybe_ save face. Do it a couple of times and the people with good intentions learn to learn.

I lose my patience when the documentation is awful. I lose my patience when searching gives hundreds of irrelevant results. (I literally looked up a command today and half the page was dedicated to telling me how to not change a password with the password change command.) I lose my patience when simple things are hard, when systems aren't self-explanatory, when I get text dumps of nonsense rather than what I need, and when have to spend half my time wrangling with finicky tools and processes built by the people who came before me. And I really lose my patience when I realize that nobody values my time except when it wastes theirs.

I say this as someone who regularly asks for help I shouldn't need to: I can't remember our processes and policies because there is no structure to them. If anything goes wrong, there's 50 places I could look to find a solution, and knowing which ones to use and when is a process of memorization, and getting it right is so unrewarding that I'd rather not try at all.

Curiosity is having a problem and caring about finding out why it isn't working. Grit is having the resolve to keep chipping away at the problem until it's solved. Patience is realizing that things take time.

Whenever a junior starts asking me things when I'm on a deadline, I politely tell them to "keep looking". I'll potentially provide a hint if it will help. Some get annoyed and scoff at me and tell me "I've been searching!". Others keep looking.

- Asking a question can be humiliating, especially if you are expected to know its answer. When a junior asks me something, I keep that in mind.

- Things that are obvious to me are not obvious for juniors. They might know X and Y but have no clue how to draw a line between them. They might not even know an alternative exists.

- If the junior does not come to me with a question, he might spend 20x actually needed time on the problem. Helping juniors is one of the best ways to meet deadlines.

- Regularly helping someone establishes trust and makes it easier to delegate to them later. More of my time saved.

- The main thing that I am teaching them is patience, I lead by example.

- I focus on explaining how to them more than what, even if I spend an hour, or have to do a pair programming session. If the lesson gets ingrained I just helped save a heck of a lot more time.

- If the same kind of questions get asked a lot, I create a doc or a recording and reply with a link.

- Different people need a different approach. It is quite likely that I am doing something wrong in how I provide help. If the person trusts me with questions but does not seem to adopt the advice, I sit down and have a "crucial conversation" with them to figure out if this is the case and adapt my behaviour.

- Some people are just stupid.. "Against stupidity the gods themselves contend in vain". Knowing when things are out of my control helps me avoid stress. That said, this is the very last resort, and rarely true. I usually try everything else before I start brushing people off and saving time for others.

For starters, I try really hard not to think of the professional engineers on my team as "juniors." They're adults with thoughts and ideas and a different context than me and they're better than me at many things. Thinking of them as juniors in my mental model makes it way too easy to condescend to them and be patronizing.

Second, what is one's value as a senior engineer? A senior engineer is usually expected to be a leader. People will follow a leader's examples - not just in writing code but how he carries himself. If a leader loses his patience, his team will think that is acceptable behavior and start trying to get away with it.

In the context of a senior programmer - they can only accomplish so much on their own while coding. They bring so much more value to the group by helping their teammates be better. That manifests itself in code review, in being present and available, in providing reassurance to people finding their footing, in answering questions, in showing people how to do things, and just being an all around mentor. You can bring so much more value to your group by elevating your teammates to your level, rather than being the lone all star.

Third, I would try to think about this from their perspective. They're probably worried they're not doing a good job, they're probably feeling some heavy imposter syndrome, and they probably look up to you as someone who knows what they're doing. They have no clue what you know and don't know, or why you wouldn't know something. Cut them a little slack and realize that you have a presence among them, whether you're aware of it or not.

Fourth, think of this practically. You're squandering so many opportunities to teach and help the engineers on your team grow. I love when someone comes to me and says, "this doesn't work," because it is such a great chance to teach someone how to use precise language to describe a process, which is a very important skill in software engineering. It's a great opportunity to show someone how to debug a problem!

When someone asks you something you don't know, and you lose your patience, you miss a huge opportunity to show them how to find knowledge themselves. If you'd said, "I don't know the answer to that question, swing over here and let's try to find it out," and then you drove through some searches and articles while they sat by, you could show them some of the things you take for granted - whether that's how to skim search results, what to search for, or just knowing your tools like keyboard shortcuts.

So I'd say try to reframe how you look at things and how you look at your own role, and how you look at yourself. It might be helpful to look at advice other types of leaders have - NCOs (Non-Commissioned Officers in the military) or Sergeants in police forces for example.

Oh boy, this is a deep topic, but generally speaking you have to come to the realization, that losing patience is almost never in your own interest. When you are faced with incompetence or laziness, or being accused for something clearly not your responsibility or fault, it's very easy and natural to let anger dictate your response. It feels right and justified.

But this is not to your benefit. Because your goal is not to defend your standpoint against an opposition - a quick shortsighted affirmation, that you are indeed "right". But to resolve the situation in a calm, rational & constructive way. In the end you can only win, when everybody wins, and that is your real goal!

And you have to incorporate that mindset and live by it. Doesn't matter if we're talking about work issues or getting angry about people in traffic.

On second point, some people need to hear that discovery and googling and figuring out and trying wrong options until you stumble onto right one is what they should do. It is not just matter of laziness, some juniors think that if they are confused and lost they are wasting time and something is wrong. They need to hear that it is ok and normal and that it is their turn to train figuring out part.

When you help people too much, they may become too used at that and wont realize when they are ready to start the harder part by themselves.

Then I got kids and I finally got it.

Loosing patience DOES NOT HELP. Ask yourself "What I am trying to achieve here, with this young padawan asking me questions? Are those questions stupid? What is the underlying reason the padawan asks the question? How can I maximize my help, what kind of response to the question supports what I want to achieve the best?"

Anyway, loosing patience only puts off the padawan and while it may help you achieve the immediate goal of not having people ask you questions I think it is just bad long term strategy. Senior people are traditionally meant to help shape younglings. If you make them not ask questions then you are very likely not doing an important part of your job.

I think long term managing that frustration... is 90% of the battle for me.

I learned after age 40 and my patience is so much better than when I was younger. I suspect it has helped a great deal.

'The more you learn, the less you know'.

Now say it to yourself.

Sometimes code is much cleaner if you exit a method or a function early. Especially in languages with automatic memory management where you don't need to concern yourself about leaks so much.

> - Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.

Lots of comments is a red flag to me. It often indicates the code itself is of poor readability. But it's usually easier to just slap some comment on it than to properly rewrite it... "A comment is a failure to express yourself in code" (Uncle Bob).

> These are just a few examples of good programming practice

I'd argue they are debatable, and at the very least not necessarily universal.

Your example is good about learning good program structure; that can save you a lot of time. You can only learn so much that way though. Sometimes you just have to make mistakes.

I've written a lot of code that is bad. But if I hadn't written that code and I was tasked to do again I'd do it the same way because there is no other experience to tell me not to do that. My sum knowledge of programming is everything I learned from school and from reading -- but the majority comes from actually writing a whole lot of crap.

It's interesting but in my experience:

> Subroutines must have one entry point and one exit point, and accomplish one task.

My subroutines almost always exit early at the top if any pre-conditions fail to be met. This is much better than a ton of nested if statement for each pre-condition. But in general it's best not to exit somewhere in the middle.

> Add lots of comments in your code to help others or even yourself in case you forget what your thinking was.

In practice, comments are pretty hard to maintain. I usually ask new applicants how they ensure a project can easily be passed off to others and if they just answer comments then that's generally a bad sign. Good hires will often laugh when mentioning comments and then describe other things like good naming, etc.

I code often as a statistician and data scientist, but am at a point I need to learn better craft. I'm all ears!

The lacking part is not knowing what you are doing (if you know what you are doing, why do you need to practice?), but having enough introspection to be critical of the code you just wrote.

Good thing every programming language nowadays enforce that lesson. I can only imagine how horrible it must've been to reason about a program when a method could just GOTO away and never come back.

    nnoremap <F5> :w<cr>:!printf "\033c";python %<cr>

And there was a time when a snotty admin convinced me that he had the authority to require me to do development in vim. He did not, and damn that learning curve was steep- but I picked up skills that still serve me well a couple decades later.

Oh, and another one - we had a process for cranking out custom reports, where if you could express the entire thing they were asking for in SQL, then you were done. But if any part of required programming logic, you had to create a controller, and a template file, and register them, and do a full product release... it was a big hassle. And man did I ever learn how to make SQL jump through hoops at that job.

So, a corollary to your "The longest way is the shortest way" is my life lesson - Constraints make you better.

For those unfamiliar with the development experience, its very similar to scratch but with a spreadsheet-like layout.

When I seriously started learning the workings of more complex logic in these tools is when I started reading the "source code" of the 2d platformer Zeb, programmed by Lee Bamber (who would later go out to make Dark Basic), drawn by Nolan Worthington.

This taught me in a very condensed manner lots of advanced programming techniques. Like a teacher of mine used to say, this will feel like drinking Fun Light (concentrated drink supposed to be cut like 1/12) directly out of the bottle.

And that tradition has stuck with me, decompiling dlls and inspecting websites etc.

Open source projects (whether corporately funded or hobby led) are run by people! So it's in your best interest to give before you take. Become active on the communication channels, answer user questions, fix issues where you can, etc... Once the lead developers recognize your name, they will be more willing to review your code (and get your changes merged when review bandwidth is low). Well run projects often have very knowledgeable people that can point out mistakes and teach you in general.

Of course, there's still value in being a "drive-by contributor" where you fix a small bug and never come back. It's just unlikely that you'll form any sort of relationship from such an interaction.