My journey in the tech world is quite unique. I graduated from university before the IBM PC was introduced and I earned my MBA before there was a world wide web. After an early retirement, I decided I wanted to attend a coding bootcamp. Now I’m a senior developer. Let me share 7 things I learned on my journey.
Read review of Day 1 here. Read review of Day 2 here.
The third and final day of ngConf switched back to a single track format. Again every attendee was in one massive ballroom to hear speaker after speaker.
After the keynote opening session, the next speaker was there to explain authentication with Angular router. Normally this is a very dry topic because the gist is user tries to access a URL and if they don’t have access then they are denied.
Luckily for the audience the speaker is also an active improv actor and comedian. He convinced 7 (staged) audience members to join him on stage, get dressed in costumes and act out OAuth.
More than half of the time of the session was getting the 7 audience members on stage, outfitted and given directions. When they actually started to perform how authentication works, it was hilarious. Especially when Mike started to improve on his role as the spinner.
Read review of Day 1 here. Read review of day 3 here.
Day 2 of ngConf is called Fair Day. Fair Day is when a single track conference goes multi-track. Not only do you get another day of great content but there are activities happening at all times of the day.
Presentations today are in multi-track format. There are three rooms with speakers so you have to choose between speakers. The schedule is somewhat unusual in that you might have a presentation that runs from 10AM — 11AM but the presentation in the next room runs from 10AM — 10:20AM.
It appears that presentations today are one hour, twenty minutes or 5 minutes long. You would not expect that you can get much out of a 5 minute presentation but you would be surprised with what you can learn.
Several months ago the organizers at ngConf had their CFP (Call For Papers) process to apply to speak at ngConf. I have spoken at multiple conferences but have never spoken at a conference of this size and status. I prepared and submitted two proposals to speak at ngConf.
Several weeks after the close of CFP, I am working on a project at home one evening and I got an alert that I had received a new email from ngConf. I read the email and it was the form letter basically saying that they get thousands of entries and they cannot accept everyone and thanks for applying but you were not accepted. I go back to work on my project and several minutes later I get a second email from ngConf. It was the same form letter but it said that my proposal to speak was accepted!
Read review of day 2 here. Read review of day 3 here.
Attending ngConf is a first for me on two different levels. It is my first time attending this annual conference. And secondly it is my first time speaking at this conference. After my first hour at the conference I came to the conclusion that it will not be my last time for either one. Here is my review of Day 1 of ngConf 2017.
ngConf is held in Salt Lake City in basically one massive ballroom in a hotel in Salt Lake City, Utah. The event runs officially from April 5th — 7th. But there are optional full day workshops that are held on a wide range of topics on April 3rd and 4th.
You only get one chance to make a positive first impression. For software engineers, the README file in your Github repo is your one chance to make a good impression to potential employers. Is your README file leaving the wrong impression?
Your README file is the most important part of your Github Repo. When people visit your repo, the first thing they will do is look at your README file.
If your readme file does not define what your code does, then most users will just skip right over it. In other words, you failed at your chance of making a positive first impression.
A good README file should include the following two items.
The description tells visitors exactly what your code does. It does not have to be an epic description that is on par with the length of War and Peace. Instead it should be precise in describing the features found in your code.
I would recommend using short sentences in your description. You can use a bulleted list if you want. Lengthwise it should be between 3–7 sentences long coupled into 1–2 paragraphs.