How To: Get Over Your Fears Of Writing And Just Get Going

Have you been thinking about wanting to write? Did someone mention to you that it might be good for your career? Or you want to write to earn some money? Maybe you just want to document your notes and share them with others?

I can’t read your mind and know your motives to want to start writing, that’s for sure. But what I can do is this: go through the fears that are currently stopping you starting to write. How do I know what these fears are? Because I have the same writing fears and I wrestle with them every day and every week.

8 Non-Programming Books You Haven’t Considered That Will Boost Your Programmer Career

Here is my latest post for Simple Programmer…

There are many lists of books about becoming a better programmer. They likely include books like Refactoring, Code Complete, The Mythical Man Month, etc.

However, in the workplace, it isn’t just programming knowledge that we programmers need. Learning programming is an essential part of our work — but it’s not everything.

The authors of iconic programming books had remarkable careers, but it wasn’t just their coding knowledge that made their careers noteworthy. They were well-rounded experts and we should strive to emulate that quality as well.

The Software Career You Didn’t Think To Consider — Professional Services

When I started working as a programmer, I assumed there was only one career path for programmers...

Here is my latest post for Simple Programmer…

It looked something like this: Become extremely knowledgeable in a given programming language until eventually you become a senior programmer.

Once you’re a senior programmer, you ride out the rest of your career as a programmer. Or you make a leap out of the technical world and into a strategy- or management-focused role.

For many programmers, this is a hard decision. Programming is what we love and we don’t want to lose our hard-earned skills. As programmers, we’re often very aware of how quickly our skills fade when we’re not in the business of putting out code anymore.

But it doesn’t have to be this way. There is another option that allows you to straddle both areas of the so-called softer and technical side of the profession.

And that’s in the realm of professional services.

How to Coach: A Cheat Sheet

"The effect you have on others is the most valuable currency there is." — Jim Carrey

Here is my latest post for Simple Programmer…

At some point in your programming career so far, you might have been asked to “coach.” Most programmers get into the field to write code, and often before we know it, we end up in a leadership role, almost as if by accident.

Only a few months into my first job I remember telling my boss that I felt like I was teaching a lot. I’d like to say it was a natural inclination towards teaching, but I don’t think that’s it. Because of the nature of the field of technology, teaching and coaching others is an inherent part of what we do. Even if we’re really new to the field.

Building a Workplace Learning Culture: Starter Kit.

If there is one fundamental truth I have come to realize after working in technology, it is this: Mindset and approach trump skill.

Here is my latest post for Simple Programmer…

For success, it isn’t the programming knowledge you or your team members have at present that matters most. Nor is it how many years of experience we have.

It’s how we work together, how we approach problems, and most importantly, how we learn. Michael Gerber said in the most eloquent way I have seen in his book The E-Myth: “Contrary to popular belief, my experience has shown me that the people who are exceptionally good in business aren’t so because of what they know but because of their insatiable need to know more.”

How unclear roles can damage your teams performance (and what you can do about it)

Roles and responsibilities can cause confusion and upset in our teams unless we take the time to openly discuss them. But, it can be easy to solve when we knew how to shine a light on the issue, here's how.

Coaching is often described as “holding up a mirror”. So that teams and individuals can reflect on what they see. It’s not about impart “right” or “wrong”. Coaching is not limited to only managers or supervisors. Coaching can be ran and facilitated by anyone in a team. 

Beyond scrum: Augmenting agile frameworks to achieve high team performance.

Agile frameworks give us our process, so what can we do to start getting higher performance out of our people - our teams

With 2018 on the horizon, I’ve started thinking about plans for the new year. That means changes that I’m making to my site, updates and rethinking my personal brand. It’s been around 8 months now since I started writing. I started off wanting my writing to be relaxed and then I’d see where it went. But now, I’m starting to think more about where I want to take it as the new year approaches.
 
My bio seemed like a good place to start. After all it is my mini-pitch of my unique take on the world. I never liked my bio because I didn’t have a good grasp of what my target topic (and reader) was. I knew I wasn’t interested in talking on this site about technical topics. Many people are already creating amazing tutorials, videos and blogs on programming and software. But, I’ve always known that the key to good software teams was not more technical skill anyway. I’ve been more obsessed with things like effectiveness. And are we doing the right thing, not only are we doing the thing right.

Writing A Punchy Junior Software Developer Cover Letter: A Case Study.

How to play to your prospective employers emotions and write a junior developer cover letter that packs a punch.

Are you going through the job application process now? Have you been asked to write a cover letter as a junior software engineer?

Not to fear. Because how to write a punchy junior developer cover letter is what we’re covering today.

To help us, we’re going to go through a real world junior developer cover letter example.

By the end of this article you should be able to analyse your cover letter critically and make the important improvements you need to bag yourself a job!

The Fatal Mistake Juniors Developers Make

Before we dive into the case study, I want to take some time to set the scene. So, let me tell a short story, if you will. The story will be useful to see where a lot of junior engineers go wrong in the job application process.

It was an evening at summer camp. We were in the staff room by the table tennis table. Throughout my entire life I’d been pretty mediocre at skill sports. So there I was, just watching the game with a sense of quiet admiration for those that were playing.

boys playing table tennis

Stood beside me was the head of athletics.

He turned to me and asked whether I would play.

Naturally, I declined. I emphasised my lack of skill and let him know that I’d rather just spectate.

He smirked, “watch”.

We looked back over at the players as he started to play out a narrative on top.

“Did you see that?” He exclaimed.

“See what?” I thought to myself, puzzled.

He continued, “every time the ball lands on his weak hand, he struggles to return it. Now look! When played to his right side — he can apply LOTS of power and win the play!”.

What unfolded for the next half an hour was a harsh realisation. I realised that I’d struggled at sports, not because I was bad, but because I’d not recognised that to be exceptional you must: watch, read and play to your opponent.

Probably at this point you’re wondering what all this talk of table tennis has to do with writing a good cover letter? Let me explain…

The tale in the story is exactly the same fatal mistake that junior developers make in the job application process: focusing on themselves and their skills but failing to tailor their communications to the person opposite them, their prospective employer.

Let’s fix that.

Creating an emotive junior developer cover letter

emoji

Okay, so we want to understand our prospective employer and their needs so that we can tailor our communications to them. But how do we do that?

First, by listing the emotions that we want to address. When it comes to hiring you, we need to know your prospective employers:

  • Suspicions
  • Fears
  • Dreams

Okay, I admit, these are a little abstract.

Let’s strep through each emotion to detail what I mean.

Confirming their suspicions

First up, they are suspicious.

But what are they suspicious about? They’re suspicious that when you start work you won’t have the skills you said you did. They’re suspicious that you were great at talking in the interview but won’t back these up with hard skill when you start.

The bottom line is: they’re suspicious that it will transpire that your skill is not as good as you said it was.

They’ll want proof.

Allaying their fears

Up next, fear.

Your prospective employer will fear that when you start the job that you’ll take a long time to get up to speed. They’re fearful that your communication skills might make it difficult to work with you. They’re fearful that you might get paralysed with an ambiguous task and request pain-inducing explicit detail.

Ultimately they’re fearful that you’ll cost them more time, money and energy than you put back in.

Playing to their dreams

Lastly, what do they dream of?

Your prospective employers dream is that they can delegate work to you and you pick it up with ease. You ask the right questions, at the right time, at the right level. Their dream is that you teach, empower and help those around you. Their dream is that you delight them in your job in ways they didn’t even imagine.

Simply put: Your prospective employer dreams you alleviate pain and make their life easier.

Writing A Punchy Junior Developer Cover Letter

Okay, now we’ve started to paint a picture as our prospective employer see’s it we’re now in a good position to start to put together our cover letter. We’re going to go through an example cover letter and update the wording. We’ll refer back to our prospective employers emotions in order to give it some real punch.

hand written book

Part 1: The Intro

At the start of your cover letter, you’ll want to introduce yourself, stating who you are, your background and why you’re unique. The junior engineer in question kicked off their cover letter as follows:

I am a self-taught web developer since 2016. As you can see from my attached CV, I was a full-time student during that year. I was just focusing on my learning, practices and building my skills. Some of my skills includes HTML5, CSS3, JavaScript, jQuery, Ruby, Bootstrap and I am on my way to add API and HTTP requests.

Let’s have a go re-writing this, and I’ll explain the changes I made and why.

I am a self-taught developer. I’ve delivered working application utilising HTML5, CSS3, JavaScript, jQuery, Ruby, Bootstrap. I’m currently teaching myself back-end development, skills such as: RESTful API’s and HTTP requests.

Improvement 1: You ARE a developer (right now!)

If you’ve written code, you are a developer. Now. Today. Immediately. In the original intro was the additional detail of the year that this individual had been developing since (It was 2016, in this case). Go through each sentence on your cover letter and ask yourself: does this strengthen my argument? If it doesn’t, rip it out. Be ruthless.

Improvement 2: Emphasise delivery

I specifically reworded the intro from “I’ve learned” to “I’ve delivered”. Many workplaces let you learn on the job — but learning should always be geared towards delivering. Remember what your prospective employer will fear. They will fear that you’ll be slow to get up to speed and start delivering. If you’ve got examples, even better.

Part 2: Why You’re Different

In your cover letter you also get the opportunity to explain why you’re unique. The junior developer here had put:

Also, I can assist my fellow colleagues and mentor interns whenever I am ready. I have some work experience in mentorship and I was doing some design mentoring when I was a regular attendee with Codecademy’s Katathons and Hackathons.

Let’s do some word-smithery:

One of my favourite ways to learn is to teach. I find teaching others gratifying and I know that in order to teach we just have to be one chapter ahead. I work as a design mentor at Codecademy’s Katathons and Hackathons.

Improvement 1: Avoid Self Deprecation 

It can be tempting to add in words like some. As the original junior engineer put: “I have some experience”. As we said in the intro, if it doesn’t strengthen your argument, remove it. You have experience. Your prospective employer will be concerned about the amount of time they’ll need to invest in training you prior to you having impact. Be confident, you have skill.

Improvement 2: Favour Present Tense

When it comes to your cover letter, if it doesn’t help your case, remove it. In the original wording, the junior developer put: “I have been a mentor”. It’s much more succinct to say you are a mentor. Saying you have been a mentor also implies that you’re not anymore, which raises the question: why? If you have been a mentor, you ARE a mentor.

Improvement 3: Emphasise Teaching

Above I added a reference to only being one chapter ahead in order to teach. This is an important statement. Most junior engineers take a long time to build up the confidence to teach others. But they need not wait. If you know something that others do not, your employer would love for you to share. In technology learning is essential, and if you can up-skill their teams you’re playing to their dreams.

The Punchy Junior Developer Cover Letter

That concludes our look over this junior developer cover letter case study.

When it comes to influence, emotions are powerful. Don’t fall into the trap of focusing too much on your own skills. Put yourself in the shoes of your prospective employer and tailor your language to play to their dreams, allay their fears and confirm their suspicions. If you can do this, you’ll have a covering letter that really packs some punch.

Are you currently putting together a covering letter? Want feedback? Send it my way, I’d love to help you out.

The important questions I ask myself every week, and why.

By rewriting your concerns as questions you move from anxiety to curiosity.
This is a paraphrased quote from the book Sprint. Author Jake Knapp is talking about gathering a list of “what could go wrongs” on a project as part of a design Sprint. Knapp is tapping into the elephant in the room and testing the worst case scenarios. But rather than listing them as statements, Jake says to list them as questions. “If we don’t get our customer to understand X we’ll fail” becomes “How can we encourage the user to understand X?”.