On the point about explaining simply, yes absolutely, and especially for design patterns and other “best practices”. Good simple explanations are things like ” it let’s you reuse the code” or “now you only need to change the code in one place instead of 10 places” or “this let’s you unit test your code”.

If you find yourself using a whole lot of techno mumbo jumbo in order to explain why you should adopt something, then there is a good chance that either you don’t fully understand it yourself, or the best practice isn’t entirely appropriate for your current situation.

One way my group likes to learn from each other is to ask for ‘sanity checks’. What this means is bouncing an approach off another developer just to see if it makes sense at a quick glance. Ideally, this can just take up a minute or two of time but can result in a valuable outcome for either participant.

For example, yesterday I had another developer ask me to check a workaround he’d built in JS based on a discussion we’d had previously. By taking the time to look over his code, I actually was able to include his approach in my own work while helping him feel more comfortable with implementing the same work.

Never presume that you have nothing to learn from a younger or less experienced developer. I guarantee they’ll know at least one thing that you don’t.

Thanks! Internet flaming is one of my bigger pet peeves for sure.

The mentality point is also crucial – that condescending or ‘bullying’ people for simply not knowing something is pointless and will come back to you. I wish the entire internet could embrace this better – we’re so quick to flame people for anything we declare incorrect.

Team Geek looks nice, thanks for the tip!

Couldn’t agree more!

I’ve met people who aren’t cut out to write code. At that point you have two options. 1) Put them on the perpetual ignore list or 2) Talk to your team (and manager) about if it’s time to cut the cord. If you’re really doing your best to help these people grow, and they just don’t seem to “get it” they’re going to draw down your team. Team Geek describes this as a toxic work environment, I really can’t recommend that book enough.

As far as becoming the big bad wolf – it’s REALLY hard to explain software engineering. Losing patience is easy. I hardly profess to be a great teacher (just ask my wife!) but I know it’s one of the most important things we can do to grow our own careers further.

That said, some people really aren’t cut out to be a software engineer 🙂
Anyway, nice article!