I have just taken the AWS Certified Developer - Associate Exam on July 1st of 2019. The result? I failed.

My AWS Developer Certificate score card

The AWS Certified Developer - Associate (DVA-C01) has a scaled score between 100 and 1,000. The minimum scaled score needed to pass the exam is 720.

I got 642

The total number of questions was 65. I did some rough calculations. With 5 more correct answers, I would've passed the exam.

Recap and reflection

• When I was taking the exam and gone over the questions, I already felt I was not going to pass. I review my questions. Nothing.
• What did I do next? I used the erasable paper provided by the testing center to write down the topic of each question.
• What did I find? There were a lot of scenario-based questions, I was expected that. Question using a combination of AWS services, I also expected that. But throttling, troubleshooting, and root cause analysis? Not so much. There were no simple questions. Nothing about SQS (Simple Queue Service), SNS (Simple Notification Service). Also, no computational questions for WCU (Write Capacity Unit) and RCU (Read Capacity Unit) on DynamoDB, which I'm also prepared for.
• What did I feel? I must've gotten unlucky with the question pool and maybe I need more time to do more real hands-on experience in using AWS services and encounter problems.

What now?

Did I regret taking the exam? No. I learned a LOT during the process.

I'm still optimistic as usual and here's my Jedi Mind Trick:

Failure makes me work hard and be more humble (makes me think I'm a human being after all).

Accomplishments (as much I love them) can make you complacent if you are not mindful.

Timeline

2018

September

I got my feet wet with AWS services

• AWS Workshop - Build a Modern Web Application Architecture by AM (Allen-Michael) Grobelny

Same speaker on a different event

November

I learned simple project ideas to create in AWS.

• Build a Serverless Portfolio in 7 days by Fernando Medina Corey

He visited us at City University of Seattle

December

I got hands-on experience with IAM, S3, Lambda, API Gateway

• AWS Serverless Workshop by Kevin Wang

Simple project created from the workshop here.

Serverless Workshop at City University of Seattle

2019

I presented about AWS services to my schoolmates.

January

My own talks:

• Tech Terms Decoded (Part 1)
• AWS S3 Quick Deep Dive Series
• AWS Elasticsearch Quick Deep Dive Series

March

Watched tons of AWS conference talks. Check my blog here on my journey in my master's program.

AWS Training

AWS Educate - Cloud Computing Introduction and Software Developer Pathway

• Cloud Computing Introduction video playlist
• Software Developer Pathway video playlist

June

I resumed my studies for AWS Developer Exam as I felt some confidence that I can do well in the exam.

Tip on how to learn again here.

• Paper presentation at CISSE 2019 Las Vegas - Serverless Computing Architecture Security and Quality Analysis for Back-end Development
• AWS Whitepapers
• Udemy course from acloudguru - AWS Certified Developer - Associate 2019
• Qwiklabs

Qwiklab courses

• Introduction to Amazon Simple Storage (S3)
• Introduction to AWS Identity and Access Management (IAM)
• Introduction to EC2
• Introduction to Amazon Elasticsearch Service
• Introduction to Amazon Relational Database Service (RDS) - SQL Server
• Introduction to DynamoDB
• Introduction to AWS CloudFormation Designer
• Introduction to AWS Lambda
• Introduction Amazon to API Gateway
• Serverless Web Apps Using Amazon DynamoDB - Part 1
• Serverless Web Apps Using Amazon DynamoDB - Part 2
• Serverless Web Apps Using Amazon DynamoDB - Part 3
• Quest: Serverless Web Apps Using DynamoDB

Conclusion

As of writing this blog, I'm moving on to other stuff for now.

My current job as graduate teaching assistant in City University of Seattle, requires me to focus on TypeScript and create content.

We are also preparing to teach Amazon apprentices and it requires us to study up Linux system administration, networking, web development, MEAN stack, and Django to able to support them.

As an Auth0 Ambassador, I need to get up to speed with identity and security. Awesome material from Auth0 here.

As an open-source contributor, I need to refactor my code and create a new pull request in the hackathon-starter repository.

Reach out here:

Twitter

LinkedIn

Till next time! Don't let failure define you =)

How often do you get the fear? What do I mean by fear? How about the knot I got in my stomach just before I plunged out of plane on a parachute jump? It’s more than the brain logically planning to avoid danger, your whole body feels it, a foreboding about what’s coming next.

Working in IT means sudden severe physical dangers are unlikely. But aversion to fear continues to exist when we get asked to do certain tasks.

In my first job, it was when my boss asked me “Have you completed the documentation?”

In my 2nd job it was “Did you send that email to the customer yet?”

And later “How’s that presentation going?”

What was the problem? All those tasks involved writing. It couldn’t get much worse than that. Very few developers like writing (unless it’s in Slack). The bigger the audience and the more important it is, the more fear the writing task brings.

Back to coding. When was the last time your code worked the first time? The time you wrote a couple of hundred lines of code that were error free and to perfection, so that it compiled and ran exactly as expected the first time?

We as developers would never expect first time code perfection, and coding is our main task. Yet when asked to write some documentation, an important customer email, or a presentation, we freeze. The empty coffee cups and Fritz Cola bottles pile up on the desk while we’re staring at a blank page, waiting for the perfect text to flow out from us.

This doesn’t make much sense. Could it be that our expectations for a side task that we often don’t like are higher than for the core task that we love and practice all the time?

Writing and coding have a lot more in common than you might think. And surprisingly you can use your coding skills to improve your writing.

As developers, we’re usually keen to jump straight into coding as quickly as possible. We don’t want to think the code through to perfection in our heads. We want to try out and experiment. We want to get a result. Once we’ve got the basics sorted then we can expand and refine our work. So much so that we’ve got terminology and methodologies to back this up. Think Scrum or refactoring.

Scrum is a framework based on getting something out there and improving it. It was created to move away from the unrealistic expectations of the waterfall methodology. Where you can theoretically completely define everything that you need to do before you start doing it.

With Scrum, the idea is inspect and adapt. Perfection is never the aim of the first sprint. Get the most important thing out in the open so it can be refined and added to later.

[Refactoring] advantages include improved code readability and reduced complexity (Wikipedia)

With code, the first version is not expected to be perfect. It’s about getting the initial version out and then improving it afterwards to make it easier to read and simpler.

Can you edit a blank page?

But what happens when you switch your favorite coding IDE for an email editor or PowerPoint? I’ve seen countless developers freeze with fear, staring at a blank screen. Unsure what to write, worried it won’t be perfect and so we write nothing. You can sense the fear when your co-workers have it, it’s the constant sighing and nervous energy of tapping fingers.

But if we’re honest with ourselves this “perfection or nothing” is the exact opposite to the coding approach that we spend all day practicing. If it was coding we’d be happy to try some of the simple cases and get it up and running. Not for writing. Perhaps it’s because we’re worried about our clarity, structure, or style. And this all before we’ve even got any words the page.

Waiting for the perfect words to form in our heads so we can just write them down is never going to happen. It doesn’t happen with coding so why do we expect it with writing.

Switching contexts can show this. Have you ever tried to refactor a program that’s zero lines long? So why are you trying to do that when it comes to documentation, email or a presentation. I like this quote from Jodi Picoult…

You can always edit a bad page. You can’t edit a blank page.

You have to actually get something down on the page before you can improve it. In Marion Smith’s book she refers to this as “vomiting” the first draft. Anne Lamott calls it the “sh*tty first draft”. One thing is clear. The first draft is not going to be pretty, but it’s the necessary first step.

Feel the weight lifting off your shoulders as you give yourself permission to write the first thing that comes to mind, regardless of the quality. With coding you want the first version to do something OK. With writing you just need to get some words on the page. Any words. There’s no compiler to reject them so what are you worrying about?

Summary

Getting a minor dose of fear before you start writing is normal. It happens to professional writers so it’s not surprising that it also happens to developers when they need to write.

My recommendations are:

• Get something on paper, anything at all. Write down whatever comes into your head.
• Use agile/Scrum rules: iterate and adapt
• Use coding refactoring rules: reduce complexity and improve readability over time

Just remember, the next time your boss asks “Have you sent that customer email out?” you’re not doing a parachute jump. All you need to overcome your fear is to vomit out your first draft and iterate.

You already have the coding skills, now you just have to apply them to your writing.

Originally published by Chris Rowe at leadtechie.com on March 3, 2019.