You should be coding

There’s no doubt about it. Software engineering as a continuously evolving and advancing discipline that often requires programmers to be equally steadfast in their advancement.

For new developers, perhaps those undertaking a self-taught journey or have recently joined or graduated from a boot camp, they will often look to the tech side of Twitter, Dev.to, and other communities for inspiration on how they can succeed in their new career; how they might become more employable and stand out from the crowd to find the success that they crave. Their efforts are not completely misguided – there’s plenty of fantastic information out there, and occasionally putting your ear to the wall can be useful in uncovering the latest trends and up-and-coming frameworks.

However, there is a sinister evil that lies amidst these communities. Many of those who garner large amounts of followers and engagement, those that quickly accelerate to the top of recommended lists and follow suggestions, are often nothing but charlatans. Of course, this isn’t all of them, but it’s many of them, and you might already know the kind of folk I’m talking about.

Those that are more social media influencers and link aggregators, than they are developers. They’ll post the same snake oil several times a day, the “learn x quick” tutorials, the free certifications, the secret tips and tricks that senior developers and industry moguls are purportedly withholding from you. Well, here’s my golden rule for handling just about anyone talking tech online:

Take anything from someone who has more time to tweet and blog than write code with a pinch of salt.

I know there are loads of exceptions and I don’t need a witch mob coming after me with raised pitchforks, the DevRels, the YouTube tech-bros, etc. I’m not really writing this article to ridicule those who produce content for other people. That would be the height of hypocrisy. The point I really want to drive home is that new developers often look to those with strong social media presence as those they should emulate.

Let me make it clear: The vast majority of software developers, especially the most senior and experienced ones, are almost certainly not cranking out amalgamations of no-code tools or the latest AI trends on Twitter. They’re almost certainly not writing article after article on Hashnode about the latest front-end libraries. They’re not doing any of these things.

You know what they’re doing? Well, funnily enough, the realistic answer is probably something not tech related. A senior developer friend of mine once told me that the more experienced developers get, the more they want to do non-tech things in their free time, perhaps tending to their vegetable patch, or perhaps playing golf. But, nevertheless, if they’re looking to upskill for an important new opportunity or they’re changing jobs? They’re writing code. If they’re not writing code, they’re reading code.

That’s the best way to get better. The talk about tutorial hell is a topic we can discuss on a different day, but the fact is, if you want to get better as a programmer, especially a green one, you should be coding. Find problems that you want to solve; things that you’re passionate about and want to resolve and figure out how you’re going to resolve it. Don’t sweat the details. Don’t worry about it being perfect; programming is an iterative process – you can make it better later! Grind Leetcode if that’s your thing!

Reading code doesn’t mean sitting with your nose in Modern Software Engineering by Dave Harley (though I highly recommend it). It means watching YouTube videos, or Twitch streamers, or even better, reading and understanding the source code of open source libraries and things that interest you. Many software engineers don’t realise it, but by reviewing their own code, and the code of their colleagues, they’re improving their own development and computational thinking abilities. It’s all nourishment for the mind.

I’d like to round off this rant by saying it’s not a bad thing to write blog posts, or to be engaged on social media if that tickles your fancy. Just don’t let it be a distraction. All the blog posts and followers in the world are not comparable to real-world experience.

So that game you’ve been thinking about? The portfolio site you want to build? The next generation social media and mobile app you know will change the world? Don’t wait until you’re more experienced, you should start now. The learning process happens by primarily by doing, secondarily by reading. Then and only then, consider writing a blog post about what you learned – we’ve got enough damn blog posts about the mystery of semantic HTML.

Tips for being a better listener from a former helpline volunteer

The Internet has a wealth of great articles with a wealth of useful advice on supporting your fellow developers, colleagues, and most critically, yourself, as you progress through your software engineering career, or whatever path you find yourself upon. This really motivated me to write my own post on this topic, one of which is close to my heart.

For a bit of background, whilst at university, I became interested in volunteering and mental health. In British, Irish, and other European universities, many students volunteer for a local Nightline – a listening service staffed by fellow students who volunteer their time supporting the wellbeing of others in their respective communities by providing a listening ear and a source of empathy when often most other services are unavailable. As a volunteer with my university’s branch, I’ve since contributed well over 1100 hours to peer support, and an additional 200 in training other volunteers – so I’ve certainly learned a thing or two!

With that in mind, here are 5 tips on being a better listener, and how you can better support others! This is a long article, I apologise, but I promise that you will learn something from it!

Please note: This is not advice or guidance on how to support someone in a crisis. Please consult a mental health first aider at your organisation, or immediate medical assistance in an emergency.

1) Make better use of Active Listening

Active Listening is the act of conscientiously listening to someone, providing feedback, and giving someone space to talk freely without judgement or advice. Three key techniques encompass this:

Summarising

Repeating back something that someone said to you to demonstrate that you are listening to them. This can take the form of literally echoing back what they’ve said:

“I’m having real trouble understanding linear search algorithms.”
“Trouble understanding linear search algorithms?”

Or can be in the form of a summarisation – summarising what they have said to you – providing an opportunity to ask a question and be empathetic.

“Thanks for telling me about what you’re going through with your new colleagues, in particular with the name-calling. Can you tell me anything more about them?”

(Open) Questioning

Again like with the example above, asking open (so questions that cannot be responded with merely yes or no) questions to encourage someone to talk.

“How is it making you feel?” “Have you spoken about this with anyone else?” “What actions have you considered?”

Encouragement

Use affirmative noises, noises like “mhm” and if the conversation is face-to-face, actions such as nodding and maintaining eye contact can help let someone know that you care and that you are listening. Don’t keep checking your phone! If someone needs more time to talk or find their words, remind them that they can take all the time they need. Remind them that you won’t judge them.

2) Don’t immediately look to problem solve

If you’re talking with someone and they ask for your advice, or for guidance on what they should do, it’s a good idea rather than to attempt to solve their problems for them, to give them an environment in which they can come to their own answer independently. You can help guide them to potential outcomes without giving your own opinion.

What do I mean by this in action? Let’s role-play.

Colleague:

I’m having trouble keeping up with my workload and it’s causing me a great deal of stress. Honestly I don’t know what I should do.

You – good answer:

I’m sorry to hear that you’re feeling stressed. Would you like to talk to me more about what’s on your workload?

You – poor answer:

You should probably talk to your supervisor about that; there’s not really much I can do to help you there.

As you can see, the first answer is empathetic and offers an opportunity to talk about the problem more. The second answer breaks interpersonal rapport and will often make the other person not want to talk about what they’re going through since you’ve already provided a solution. Chances are – they’ve already considered that anyway.

Furthermore, there might be further underlying reasons for them wanting to talk. They have initially mentioned workload, but by probing further into their situation, there may be other underlying causes, perhaps a bereavement, illness, etc. that might be contributing to the difficulty keeping up with their workload.

3) Use their language

Of course, I don’t mean a language itself (like French), but rather what words and terminology someone uses, you should mimic naturally when you speak to them.

Believe it or not, we tend to do this subconsciously anyway (code-switching) but making an active effort to live in their world and use the terminology that they use can help you build a rapport with someone and to let them know that you are attentively listening to them. This also helps you avoid making any assumptions, as you’re only using words that they have given you.

For example, if someone wants to talk to you about a problem they’re having with their partner, then use that word. Don’t substitute it with boyfriend, girlfriend, wife, husband, whatever, and vice versa. It should go without saying, but this extends to people’s preferred pronouns also.

Exceptions apply. You don’t need to use phrases or words you feel uncomfortable with, or that are derogatory. If in doubt, ask.

4) Avoid using the word ‘why’

The term why can sometimes feel judgemental or confrontational. Consider the two examples:

With why:

Why do you feel that way?

With an alternative phrasing:

What makes you feel that way?

It seems simplistic and almost nit-picky, but you will find that many active listening programmes will encourage avoiding the term.

5) Understand the difference between sympathy and empathy

Sometimes we use the terms interchangeably in the English language – but they are different emotions. Empathy is vulnerable and requires a commitment to coming down to someone’s level to experience their emotions and experience as they do. Sympathy, is simply: “that’s too bad.”

The best explanation for this comes in the form of a short animation by Dr Brené Brown. I implore you to give it a watch!

Conclusions

From this article, I hope that you are able to understand a little about Active Listening, how being non-directional and non-judgemental can aid your conversational skills and support others, that your choice of vocabulary can seriously matter, and the dramatic difference between empathy and sympathy.

These skills can be lifesaving and will help you in your everyday job, your interpersonal relationships, and even with your own wellbeing.

Remember these golden words: If in doubt, ask!

Thank you so much for reading.