I thought it was about time that we got in touch and just said hello!

I know that we’ve been pretty quiet on Medium but I just wanted to let you know that we haven’t given up on Career Change Coders and, in-fact, we are very much alive and kicking!

We’ve recently launched our new website and the Slack Channel is going from strength to strength. If you haven’t signed up yet, please feel free to join the community and come and chat with some like minded, career changers, who are all learning to code.

Speaking of code, what are you working on at the moment? What are you learning? Drop me an email and let me know, I’d love to hear how things are going 🙂.

Me? I’ve been working on a few interesting things lately. I’ve rebuilt my own website using Jigsaw (I wrote a little bit about Jigsaw here) and I‘ve also been working on a couple of side projects, The Py Files and The JS Files.

Basically, I wanted to get to know some of the awesome developers from the Python and Javascript community a little better and so I decided to conduct a series of interviews with them. Check those out and make sure you sign up to get notified when new interviews are released!

The first interview is with Joseph Mancuso, creator of the Python web framework Masonite. Joe was kind enough to talk to me all about the framework, his motivations for building it, his dev-setup and how he manages a full-time job along with school and a family! Well worth a read! 🔥

I’m not the only one who has been busy either, about 6 months ago, David landed his first job in the industry, doing some project management, working remotely for a web agency.

He’s also currently busy rebuilding his portfolio, using Jekyll, in preparation to move forward in the pursuit of a frontend developer role. Exciting times, and I’m sure there will be more to come on that later!

Anyway, It’s been good to catch up, I promise it won’t be so long next time, but in the meantime, do come and say hello on Slack!

All the best and happy coding,

Rick

Career Change Coders

Hey Coders! 🙂 was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are like me, you have tried dozens of courses and resources that promise you will learn to code quickly and easily. I’ve already debunked that myth (here), as have others (here and here). Learning to code has many layers from learning the actual programming languages to learning how to think like a programmer. Complicating the learning process is the fact that everyone learns differently. In education, the concept of differentiation is critical and means that teachers provide instructional strategies that support the various learning styles of their students. But what are learning styles? How do you recognize your dominant learning styles? How do you find the best coding resources to meet those needs? In this post, I’ll address all three of these questions.

Learning styles are simply your preferred method of learning new material that enables you to comprehend and retain content. Learning styles are not fixed. Meaning, you can have multiple dominant styles, and these styles can change depending on the material you are studying. Knowing which are your dominant styles can help you choose the right coding resources to be more successful.

There are seven widely recognized learning styles.

Verbal/Linguistic

Characteristics of learning include reading, speaking, and writing. Generally, most courses and resources for learning to code emphasize this type of learning since reading documentation is key to becoming a great programmer. Therefore, I highly recommend the FreeCodeCamp program where you learn by reading snippets of documentation and then immediately apply what you have learned. Join the FreeCodeCamp community on Facebook, and you can discuss problems and solutions, and share your progress. Sign up for newsletters and blogs. I really like JavaScript Weekly and CSS-Tricks. Resources like W3Schools and Mozilla Developer Network are also perfect for you. But not everyone learns this way; so if you need a more differentiated approach, keep reading! Don’t discount FreeCodeCamp just yet, because they have enough differentiation to meet all of your learning style needs.

Visual/Spatial

Characteristics of learning include using color, graphic organizers, reliance on images and pictures, and use of visual media. Visual learners love their text editors because most editors use color to consistently indicate specific code. Try mimicking that process by taking notes in color, specifically on new vocabulary words. Creating wireframes (here) is a great way to visually conceptualize your development projects. Choose coding resources that were created with diagrams and images. My favorite visual resource is The Ultimate Flexbox Cheat Sheet. The positioning of the images with the color blocking in this Cheat Sheet makes learning Flexbox more accessible. If you are working through FreeCodeCamp, I recommend looking into The Daily Programmer YouTube series. Here, Cody Seibert walks you step by step through assignments using a white board to tease out concepts before you code.

Auditory/Musical

Characteristics of learning include listening to audio books, podcasts, and lectures, linking sound with meaning, and adding rhythm and rhyme. Good speakers convey meaning through use of tone, inflection, and speed. This is important for coders because of the amount of new vocabulary we have to learn. Hearing the vocabulary in context makes it easier to pick up. I happen to love Jose Moreno’s YouTube videos that accompany the FreeCodeCamp curriculum. Mostly, Jose talks through the instructions. Something about his voice and hearing the words out loud enable me to access that part of my brain and solve the challenge. If you are looking for great coding podcasts check out this link. I am enjoying Start Here FM, a relatively new site, mixing audio, video, and a book club based on various topics.

Physical/Kinesthetic

Characteristics of learning include movement, manipulation, and hands-on activities. Kinesthetic learners don’t mind broken code because they enjoy fixing it. Here, learning takes place in the transformation of information into a product. Building is critical when learning to code, and you can start building the minute you learn some basic HTML and CSS. Take courses that encourage you to build your own projects rather than just copying the code from an already completed project. FreeCodeCamp provides such tasks at the end of every unit. You may start with a simple Tribute Page, but you will end up creating a Simon game, a calculator and much more. Try to build something everyday just to experiment. If you run out of ideas, find inspiration at Rosetta Code.

Logical/Mathematical

Characteristics of learning include systematically and sequentially working through problems, understanding cause and effect, and running simulation-type games. Logical thinkers tend to like workflow applications, read documentation, and utilize libraries (like Bootstrap) that rely on an understanding of hierarchy. Arguably, we can say that learning to code is all about problem solving, so take the opportunity to get involved with puzzles, challenges, and gaming at CodeFights, CodeWars, HackerRank, and CodeInGame.

Interpersonal & Intrapersonal

Regardless of your preferred learning styles, most people fall into one of the last two categories: Interpersonal and Intrapersonal.

Interpersonal learners like the social aspects of learning such as study groups, so why not participate in a local Hackathon, attend a programming meet-up, or join a study group (FreeCodeCamp has study groups all over the world. My group meets every other Sunday, and it is my favorite part of the program). Women — join the WomenWhoCode organization and get involved in your community. Give back by working on open-source projects on GitHub.

Intrapersonal learners prefer to work alone and often focus on self-reflection, so why not participate in a challenge like #100DaysofCode or #30Days,30Sites. I participate in both challenges, and everyday, I post an update on my Twitter feed to hold myself accountable. Start a reflective blog about your learning experiences (exactly like I did), and join GitHub to participate in open source projects on your own time.

Wrapping Up

I have no doubt that as you read, you identified with several learning styles from your journey as a student. If you want to analyze your learning styles more formally, take this learning styles inventory. One last note, to make the most out learning to become a programmer, you should address as many learning styles as you can. Build up your knowledge base with resources that match your dominant learning styles, and then venture out into different styles, but be patient with yourself. Learning to code is not quick and easy. Give yourself permission to make mistakes.

I’m always interested in hearing other people’s stories about learning to code, so I challenge you to write a comment or send me an email telling me what your dominant learning style is and your best resource for that style.

Thank you for taking the time to read this post. If you found it informative, please hit the heart button.

Don’t forget to join me on Twitter and Career Change Coders on Facebook and Slack

Understanding Your Individual Learning Styles in Relation to Learning to Code was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Entering into a career change to become a web-developer and embracing the full-time commitment that entails, meant I had to take stock of how I managed my time.

I am a husband and a Father of two little kids. I had to be ruthless in what was important to me and what wasn’t. So this was my process and these were the questions I asked.

• What are the essential tasks I need to complete every day?
• What tasks are important to me?
• What tasks are important to my wife and children?

What are the essential tasks?

An essential task is a task that needs to be done without exception. These tasks form the building blocks of your day. It could be anything.

• Making dinner.
• Doing the washing.
• Paying bills.
• Taking kids to school or other events.
• General errands.
• Job.

It doesn’t matter how detailed you are. But separating everything helps paint a clearer picture of potential tasks that can be grouped together and at what time in the day they can be performed.

The point is to sit down and be totally honest with all your general day to day stuff and ask yourself, ‘is this essential and if so, is there another way to be more efficient with it’?

It all boils down to priority. What is your priority? At the end of the day if you are changing career — what is the end goal? Changing career is a pretty big deal, but if other things continue to find themselves dominating your time, one has to ask the question, ‘what is the drive behind changing career and is your belief in it strong enough’?

Sitting on the fence and looking over to the other side will always have a stronger appeal to what you already know. It’s called curiosity. We as humans are suckers for it. Don’t fall into the trap of thinking it will be better on the other side.

If you find yourself constantly back and forth in your drive to practice and learn. If you find life just keeps getting in the way. Do this process. Write down what is important and why it is important.

Eventually, you want to come to a singular truth and desire. That is your key. Hold that truth high like a lantern shining on your path. That is what will pull you through when the going gets tough and the motivation crashes and burns. Why are you wanting to learn coding and/or change career?

Building your day as blocks of essential tasks

On my list, I highlighted quality time with the family as an essential choice. It was in this process of highlighting what I needed to change in order to free up more time for coding, that I turned family time into a task. It sounds very impersonal, but for me it changed my whole outlook on how I organise my day.

Knowing that at a certain point every day I had to be completely present for the family meant the rest of the day I could decide, without guilt, that I could prioritise coding if I needed. Regardless of what I was doing I was totally focused on the family. I left my phone alone, didn’t engage in anything. I was just present.

A simple example of this. The other day I was down by the river and my son was throwing stones into the river (his favorite activity at present). I sat nearby and just watched. It was actually a prime time to read an article or do some quick emails. He was happy and there was nothing else I needed to do.

But I left my phone firmly in my pocket. In 15 minutes he looked over 3 times and each time I was there to affirm his activity. I don’t share this story to say wow what a gracious Father, not at all. I share it because in that moment I learned the difference between being present and being engaged.

Since that moment I have seen a number of parents who are out with their kids but are glued to their phones.

On another day, I had taken my son to a playground. A little boy was there with his Father. The entire time the Father was on his phone and the son constantly looked over for affirmation that never came. I am not judging that man because I don’t know his journey.

But I do know he wasn’t engaged with his son in a precious moment. I have been that kind of Father myself, many times, constantly looking for a moment to check Facebook or emails. Or quickly watch a few minutes of a coding video.

Since changing this mindset, my relationship with my son has become so more alive. I spend less time with my kids now, yet I have a richer relationship with them. The same goes for my times when I am studying. They are much more focused and I gain more progress in those times. But why is this?

Being present and being present

There is being present and then there is BEING present. You could sit on the sofa with your spouse and both of you are on your phone. Both spouses are present, but are they engaged with each other?

Having tasks or blocks to your day simply helps your sub-conscious approach that task with the mindset of engaging with it. If you engage with something you will take it seriously and appreciate it is an important time period. This will automatically make you more focused and will guarantee a more productive return on your time investment.

To summarise

Reorganise your day into what is essential and what is important. The important parts can then be reordered into most important. When you run out of time in the day those important things that didn’t make it, just have to be removed from your life.

It is brutal, but if you want to be productive you simply must do it. That is why your desire to change career has to be a strong one. The plus side to this. If you find success in re-focusing your day you will definitely appreciate the new lease of life it affords.

Finally… with regards to social media (which IMO is such a destroyer of focused quality time). Perhaps a good idea is to turn off ALL notifications for every aspect of social media and setting aside a portion of your day to focus on social media activity — replying to post and message etc. This is a much better and more focused way of dealing with social media.

I wish you all great success in pursuing your dreams. All it takes to achieve that impossible goal is one step forward. Everyone can run, it just takes one step first…

How I revolutionised my productivity and became a better Dad in the process. was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

A quote widely attributed to a wise man named Pablo goes something like this:

Good artists borrow, great artists steal.

This holds true for the developer world. The best way to level up is to constantly watch the pros and imitate their styles until one day, your code is as effective and DRY as possible.

But then how can a portfolio and online presence stand out? If I imitate other developers, where do I get to differentiate myself and plug my own personality for all potential business partners or employers to see. While Pablo the Philosopher gives good advice for how to advance your skills, Pablo the Artist exemplifies what one can do to create a brand that is different from anyone else.

Keep It Simple, Simpleton

Your portfolio is a precursor to a resume. Think of it as an elevator pitch on screen. Keep the navigation simple. Instead of building the resume in something like React, just use HTML and CSS (and perhaps a touch of jQuery), then let your projects on display let visitors know what other skills you are capable of.

Project Your Projects

Include some projects you’ve worked on. If you’re constantly applying to Python jobs but have no interest in Java, include mostly Python stuff. Your audience is folks who have never seen your projects beforehand, so give context as to what the project is, why it was built, and when. Seeing multiple projects done a few months of each other can show drastic improvement.

Portfolio Picasso

Unless we’re talking about the recent machine learning phenomenal called style transfer (which I would totally check out, by the way), your style is yours and yours alone. Whether this is represented in a project or through your online portfolio, those visiting your site should get a good glimpse into your personality and interests. Some portfolios may also get more in depth, proclaiming a favorite band or sports team. This could work for or against you, considering your visitor may have little interest in Lebron James or basketball at all.

Regardless, having something stand out about your online presence tends to work more in favor for you because brings together interests that may lead to a better professional relationship relationship. Employers are looking for someone who is able to code well, but they also want a coworker with whom they can relate.

Links to the Past

While the profile should remain simple and just give brief insight as to who a developer is, links to other profiles (especially GitHub or LinkedIn) could serve as the next stage if the visitor is interested. Marketing one’s skills on Twitter or Instagram have also become pretty popular as of late, but aren’t mandatory.

Get Inspired

As much as you want your online presence to be the clearest rendition of who you are, inspiration can come from everywhere. Similar to how you gravitate to a particular piece of art in a museum, use other portfolios to give you a better sense of what interests you. On Dribbble, you can search through projects by color — an excellent method of discovering what kinds of colors resonate with you and how you’d want yourself portrayed to others.

Make It Your Own

Developers are lifelong learners. With this in mind, I can definitely admit that I am a different person than I was in high school. My ideal portfolio as a teenager may have looked very different from what it is now. With a portfolio, I am able to market my present self in however I see fit.

What to Consider When Marketing Yourself as a Developer was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

My exploits into Javascript unearthed a very clear revelation recently.

If I want to understand what it is I am really trying to build — I must first ‘think’ in the language with which I build.

Stumbling about from one problem to another, trying to understand how arguments work, functions execute and all the above. I concluded quite simply, I did not know the basics well enough. It is all very well and good copying code and watching tutorials (nothing wrong with that at all). But actually thinking a problem through from beginning to end is a totally different beast.

Last week I spent 5 hours trying to reverse a string. As a newbie, I had no idea how to do it. I refused to even look for a hint, let alone the answer. In the end, I managed to achieve 90% of the task.

That experience broke me in some ways. I felt such strong emotions ranging from failure and frustration to hopelessness and stupidity. You can’t help but shake that overwhelming sense of ‘what is the point’?

So what was the revelation that I had?

Think in your head what the code is actually saying to the computer.

7 years ago I moved country and with that, I had to learn a foreign language. There comes a point when you go from being able to speak short sentences to make yourself understood — to being able to have a fairly normal conversation. Even though your vocabulary doesn’t increase much, the divide between broken sentences and flowing conversation is huge.

If you want to ask a question or make a statement, you first think that question/statement aloud in your head using your native language. Then you translate it into the new language.

In time, however, you begin to think in the foreign language and it is at that point your communication goes from stagnant sentences to flowing conversation.

This same cross over also occurs in programming. When we learn to actually ‘think’ like the computer does, then we will really enter into the realms of mastering that language. So how do we achieve this?

1 Speak out load the different elements of the code.

2 Remember computers read from right to left.

3 Use the proper language when speaking out load.

This is a problem taken from FCC.

reverseString("Greetings from Earth");

function reverseString(str) {
    var arr = [];
    var array = str.split("");
    for (i = str.length - 1; i >= 0; i--) {
        arr.push(array[i]);
    }

console.log(arr.join(""));
}

So if I was to read this out load and also bare in mind going from right to left.

var array = str.split(""); 

//take my string, split each character within the string (that is what the "" does) and make a new string with each character. Put all the new strings together inside a new array (.split method does this). This is what it would look like.
["G","r","e","e","t","i","n","g".......] and so on.

arr.push(array[i]);

//For each value of i repeating through the loop (above), take that value as the position in the array and push out that element into the new array I created earlier. 

Although I have done a horrendous job of trying to actually explain what I mean. Hopefully, you get the idea. Break each component down, understand what it does, speak it out and logically follow that order through. Loosely go from right to left.

If unsure, test it. Test each section with a console.log() to see if it gives the result you were expecting. Try and figure it out before searching for the answer.

Figuring out these tiny details, although extremely painful in the moment, does produce a wealth of understanding that doesn’t become apparent until after the problem.

Do this process again and again and again. Over time it will become natural and you will start to think like the programming language itself.

All the best on your coding journey.

Join us on Facebook & Slack.

Want to master programming? Try this process. was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quick disclaimer. I am not promoting one text-editor over the other. They are all brilliant. A big thank you to all the people that made these amazing editors.

I personally use Atom. I will mention the packages for Atom first. The equivalent packages for brackets [B] and Sublime text [S] will be listed at the end of each section.

1 Live view.

Atom-HTML-preview | Atom-live-server | Browser-plus | Open-in-browser.

These are all versions of a similar thing. They basically incorporate the ability to have a live view of your progress as you code. Choose which you prefer. I have found HTML-preview to be glitchy on some occasions.

[B] Already integrated. [S] Browser-refresh | View-in-browser.

2 Emmet.

I won’t go into the details of this particular package because it is loaded with a lot of features. It is simply a must. Get it.

Same link for all 3 editors. Emmet.

3 Beautify | Atom-css-clean | Aligner | Atom-css-comb.

These packages will add all the correct spacing and indentations to your code. They will align everything cleanly and correctly. Beautify can be used for nearly all of the different programming languages.

[B] Beautify | CSS-comb. [S] Prettify | CSS-comb.

4 Color-picker.

Using the shortcut ‘cmd-shift-c’ will bring up a color palette where you can choose a whole host of colors. Includes RGB, HEX, HSL, HSV, and transparency.

[B] Color-picker. | Swatcher. [S] Color-picker.

5 Color-pigment.

This basically highlights the color value in CSS. For example, #fff will be highlighted white. This gives a nice visual overview of the entire file.

[B] Color-marker. [S] Color-highlighter.

6 Autoprefixer.

Will scan your CSS file and add additional prefixes to your code for older browser support.

[B] Autoprefixer. [S] Autoprefixer.

7 File-icons.

Adds color and the file language symbol to all your files throughout your text-editor. Gets rid of the boring default file symbols and gives better visual referencing.

[B] File-icons. [S] File-icon.

8 Duplicate-line-or-section.

This basically adds the ability to duplicate a line or highlighted section for Atom using cmd-shift-D. Sublime and Brackets have this already integrated. Saves having to copy and paste all the time. Really is a simple, but brilliant package.

[B] Integrated. [S] Integrated.

9 Mini-map.

This adds a small column, outlining the overall view of your code, to the right of your main pane. Gives a better overview, for improved navigation.

[B] Mini-map. [S] Integrated.

10 Highlight-line.

Simply adds a solid line of color to the top and bottom of the section you are highlighting. Just offers better visualisation when highlighting sections of code.

[B]Couldn’t find one. [S] Check first comment at the end for solution.

11 Highlight-selected.

If a word appears multiple times it will highlight all of them by clicking on a single one.

[B] Quick-search. [S] Word-highlight.

12 Linter.

Linter is a program that scans your code and reveals errors. Missed ; or space or {. Whatever the error, it will reveal it. Linter is present for multiple languages. Usually, you have to install the main linter package and then add the individual linter-specific-language add-ons.

linter-csslint | linter-scss-lint | linter-sass-lint | linter-htmlhint | linter-jshint

[B] Brackets-interactiveLinter. [S] Linter.

13 Git-plus | Git-plus-toolbar.

Gives you the ability to add, commit and push to your GitHub account without using Terminal. Offers various other features.

[B] Brackets-git. [S] Git.

14 Todo.

Almost like a todo list app inside the editor. It will search across multiple files for the todo you are searching for. Has a separate pane to manage and select all your todos. It is a complete package.

[B] Brackets-todo. [S] Todo-review.

15 Ask-stack.

Type your question and it will open a stack browser inside the editor. Has multiple options and gives quick access to answers your need without leaving your text-editor.

[B] [S] Could not find alternative.

16 PlatformIO-IDE-Terminal.

Opens terminal inside of the text-editor so you don’t have to leave it. Has lots of editing features, colors and texts etc.

[B] Brackets-terminal. [S] Terminal-view.

17 Atom-minify.

Gives you the option to minify your CSS and JS files inside your editor.

[B] Minifier. [S] Minifier.

18 Advanced-open-file.

A better more comprehensive ability to control, find and make new files within the editor itself.

[B] [S] I believe both are already incorporated.

19 Jumpy.

Jumpy is an interesting package. Using the shift-enter shortcut brings up lots of mini keybindings, that once typed in will instantly move the cursor to that area. Sounds weird. Visit the link for full understanding. Gives possibility to move around the text-editor without using a mouse.

[B] [S] Not found an equivalent.

20 Quick Editor.

This package allows you to editor your CSS within an HTML file. Very similar to what is native in Brackets.

[B] Incorporated. [S] Not found.

That is all for this week. I hope some of these packages bring fruition to your coding. Until next Sunday… peace out.

Join us on Facebook & Slack.

20 brilliant add-ons for your text-editor. Guaranteed some are new! was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

React is fun. After just a week, I’m seeing a completely new way to tackle the frontend and frankly, it’s both visually appealing and increasingly terrifying. If you’re new to React like me (or haven’t touched it at all), my first impressions would be of those Matryoshka dolls from Russia. There are many dolls, but through a series of doll-inception, all sized dolls can be contained within the largest. In terms of organizing your code, this is neat. Components may be stored within larger components, which in turn render any actions in your application.

Yes, that’s cool, you say, but is that all there is? Is the whole hype-train coming from a bunch of OCD developers who like to keep their code as tidy as possible?

Maybe a little. But wait! There’s more! Just take a look at this code!

render() {

return (

<div className="App">

<Header onClick={e => this.resetGame(e)}/>

</div> 
   )
}

In the first line, we’re calling a render function. Pretty standard stuff in JavaScript. Within that we have a return followed by a parenthesis (semi-weird) and then what looks like… HTML… Is that you? Things are looking odd. Then, within that header, we have an arrow function and… and… okay, this is full-blown weird.

Or not.

This is what’s called JSX, a syntax extension of JavaScript that allows us to do our typical JavaScript coding that has the structure of HTML.

Which brings us to Babel.

In 2015, ES6 became the latest release of the ECMAScript language specification, but up until now, it has not been standardized. Certain browsers still cannot support ES6 functionality, which is a shame, because arrow functions are pretty awesome (especially since they transcend the lexical scope and change the meaning of the ‘this’ value).

Fortunately, there is a solution. The JavaScript compiler Babel is able to take everything it sees and turn ES6 into code that runs on whatever browser you’re using. That includes the funky stuff, like JSX, spread operators, and arrow functions .

What this does is give a React application a unique feel that feels surprisingly comfortable. Consider the following HTML:

<button type="button" onclick="handleClick()">Click me</button>

…and then imagine this function running in the JavaScript file:

function handleClick(e) {
  alert('I just got handled')
}

This simple pairing is similar to how React uses what are called Props — short for properties.

Remember the Russian doll analogy? What’s cool about React is that the parent component (imagine the largest of the dolls) can send down properties to its children, who in turn use these properties in their much smaller component. What ends up happening is each smaller stateless component is used specifically for one use, making it extremely easy to figure out what the point of a specific component is. This is especially important for folks like myself who have to work on ameliorating their disorganized code.

There is plenty more to learn in React, as I still have yet to tackle Redux, the state manager of the bunch. I’m especially excited about the capabilities of React Native, and how it can build mobile applications for both iOS and Android.

Major Props: First Thoughts on React was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

I saw this Facebook post crop up on one of the various ‘newbie programming groups’ and i’m pretty sure it’s a feeling that everyone can relate to…

Do any of you ever just get overwhelmed and discouraged by how much you don’t know, and a feeling that you’ll never get to the point where this all “pays off”?

I’ve been working on FreeCodeCamp for the past month, and I’m enjoying it, but I also sometimes get this creeping feeling that it’s all a waste of time because I’ll never “be a real developer”, or even have enough knowledge to pretend I’m one. Does this happen to any of you, as well? What do you do to combat it?

My response…

I think everybody gets this feeling, but you’d be surprised how little you really need to know to get started.

I work as a junior developer, under a top senior developer with 20 years experience. His favourite thing to tell me is…

“you don’t need to know everything to be productive”

He will often be researching things and searching Stack Overflow for solutions. Why?…because you can’t know everything.

Instead, my advice is, be confident in what you do know. You are never going to feel ready to apply for that job or start that big project. So you might as well stop waiting.

There are software features, bug fixes, websites to develop that are perfect jobs for a beginner or someone with your current skillset to work on.

Know only a little html/CSS ?— you can already use a template and build a static site for someone — Know a bit more and you can develop this from scratch.

Know a little jQuery or JavaScript? — You can add some pretty nice features to these sites.

Learn a little PHP and you can add a working contact form. Learn more PHP and you can start working on custom Wordpress themes.

…Learn how to use Google and you can build anything!

Seriously though, you get the point. You can be productive and useful with even a basic skill level. And you will learn most by jumping in head first and building these things. Stop thinking that you shouldn’t apply for that job, or take on that freelance project. Although you may only have basic skills, you can always bring value to someone!

Try not to worry about React/Angular/Rails/Laravel or the other next big framework until you have the fundamentals down. These will just confuse you, over complicate things and overwhelm you more. This all comes with experience!

Confidence comes with building things and getting shit done!

Focus on what you do know and don’t worry about what you don’t! Keep Going! Build things! You will be surprised what you are capable of!

Thank you for reading! :-) If you enjoyed it, hit that heart ♡ button below. I really appreciate your support and it helps other people see the story.

I am always happy to hear from like minded people, so please, feel free to say hello on twitter

Learning web development? Feel like you are getting nowhere and that it may never pay off? was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

A week before writing this, myself and another coding newbie wanted to build an app that recommended interests based on past likes. We would use the TasteDive API, which contains a database of books, movies, and music built upon similarities. Long story short, this would be the biggest project I’ve ever tackled.

Schemes of Schema

I didn’t sleep much this past week. Quiet night hours were spent researching how to do specific things like create a schema using Mongoose, then add a sub-schema within that first schema.

The point of the schema is to hold onto users in a database (living on mLab), then having each of those users have a curated list of things they enjoy. If you take a look at the listSchema, after adding a particular movie (let’s say Die Hard) to his/her list, a user could give the date which the film was seen and a rating out of five. While that was the initial plan, timing only allowed my partner and I to add names to the database. I’d also like to mention that the userSchema currently has all required fields set to false. When you do as much testing as we have, constantly logging in is a burden that we did not want to deal with.

Connecting front to back

When first planned, I didn’t realize the intricacies of connecting the front-end (where all my event handlers and things were living) to the backend (where all my endpoints were living). What we ended up doing was creating a cookie that logs a username on the front-end, then is brought to the backend for storing the user in a database. While I’m an advocate for frequent cookie eating, the use of a cookie for this purpose is still a bit new to me, so it ended up causing more of a headache than anything.

Testing… 1, 2, 3

Before I make any promises, the current state of this app is ‘in progress’ so while we are using Travis CI to check our tests and Heroku for deployment, there are still a few bugs that need to be worked out. This means the app is currently only working properly on my machine (UPDATE! The app is currently living here).

Starting this app, I wasn’t too keen on testing. It seemed like a waste of time that I didn’t necessarily have. However, the integration of Mocha and Chai has led me to believe I went about this project all wrong. Testing is important, especially for a big project that has plenty of bells and whistles. The initial planning stage should have included more of a documented chart of the user experience. If I click this button, at which endpoint do I end up? When I update this entry, am I correctly using a PUT request?

The biggest takeaway from this first seemingly huge app is that the amount that I’ve learned outweighs the amateur look and feel for my code. I know this can be done cleaner.

The “Finished” Product

Finished is a strong word, but at least there is a semi-working app now.

Thank you for reading! :) If you enjoyed this story and are interested in others like it then please recommend, share and follow the Career Change Coders publication. Your support means a lot to our community.

If you are currently on your own journey and would like to share your story and experience with others, in a similar position , then please follow our guidelines on contributing to our publication.

Career Change Coders are now on Slack. Please join our team and help our community grow bigger and better.

Frontend, Backend, and the Dinosaur in Between was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.

This grey box indicates what you should write when executing commands in terminal/command-line.

ALWAYS write exactly what you see in this grey box. Hit enter to execute the command.

1 Basic ‘chain of command’.

This is what you do to update your files on your computer (local) to GitHub (host). These commands assume you have already set up a repository (repo). Section 3 covers, creating a repo.

1. git status
2. git add
3. git commit
4. git push

This is the basic chain of command you will use every time you update your files to GitHub.

git status

This asks terminal what is the current state of play with all your files in your repo. It will highlight everything that has changed in red. Usually, this is divided into two sections — changes made to existing files and new files created. If you have deleted files this will also show.

git add .

This will add ALL updates made to ALL files and will also add ALL new files created. That is what the full-stop does — basically ALL. You can additionally just add the file name instead of the full-stop to add individual files. For example…

git add index.html 

Once you complete this command and performed another git status, everything will turn green to indicate files/changes have been added. Important to note, although they have been added they still need a final confirm action.

[for those interested, but not important for this blog piece, there are two other related commands “git add -A” and “git add -u”. I’ll let you explore the differences here].

git commit -m “write your own message” 

This is the confirmation. Everything has been added and you have told terminal to send the updates to your repo on Github. The commit is basically you saying ‘yep I commit to this action — confirm’. Notice it is good practice and mandatory to write a message, this is the -m part, (m) for message. Always include the message inside of quotation marks. The message is basically communication with others who may also be working on the same file.

git push

This is your final command. Everything is ready and you have confirmed. Now to just press the send button and off it goes — your repo is now fully up to date.

Git status is just a visual helper and is not expressly needed to update your repo to GitHub. Steps 2–4 are needed every time, however.

2 Navigating within terminal.

Here are the commands to search and locate your repository files.

1. pwd
2. ls
3. ls -a
4. cd
5. ..

pwd

=print working directory. In other words, tell me where I am. It will list the hierarchal file tree including the directory you are in.

ls 

=list. This command will list all the visible files in that directory. Does NOT show hidden files.

ls -a 

=list and list all hidden files. Will show all invisible files as well. By default, invisible files are not shown in terminal.

cd your/file/location 

cd=call directory. This is basically the command telling terminal I would like to go to this directory. It does not work just writing your repo name. It is not like spotlight or search. You have to write the entire hierarchal tree or file pathway. By default, terminal will always start you in the very root file of your computer system. This is defined by this symbol ‘~’.

So an example… I called my repo ‘pigs-can-fly’. For some reason, I put it in loads of other files. Let’s say this is the tree pathway to get to my repo ~/documents/my-files/pigs/pig-pics/another-pointless-file/pigs-can-fly. This is the full path and so, therefore, this is the full command

cd documents/my-files/pigs/pig-pics/another-pointless-file/pigs-can-fly

I don’t need to write ‘~’ because I will automatically start in that repository. Unfortunately, you cannot just write

cd pigs-can-fly

-

cd 

and

..

These two commands will navigate you between repositories. Say I am in ‘pig-pics’ and I type cd I will go straight back to the root file ‘~’. If I type .. I will go back one directory — so I’ll end up in ‘pigs’.

That is navigating with terminal.

3 Setting up a repository.

This is performed via GitHub.

On GitHub go to Profile Page>Repositories Tab>NEW (green button)>Name the Repository>Add a README file (good practice)>choose whether to add .gitignore file. DONE.

[README file is basically a log or diary of what you are doing or making. .gitignore is a file that tells your repo to ignore other certain files. Read more here.]

Once you have set up your repo, open it, and then press the green clone button. Copy URL inside.

Now we need to link GitHub to your computer. We don’t have to create any files on your computer. Simply open terminal and type this command.

git clone “url just copied”

URL goes inside quotations and job done. Terminal will create a file with the same name as your repo. Important to note this file will be placed in your master or root file on your computer (usually this file is named after you). If you want the repo to be saved in another location make sure you are in that directory before you perform the clone command. So if I want my ‘pigs-can-fly’ repo to be saved in the ‘another-pointless-file’. I have to make sure I have navigated to ‘another-pointless-file’ first.

NOW, WHAT IF… you already have a project on your computer that you want to upload to GitHub? How do you do this on terminal?

First, make a repo on GitHub and copy that URL. These are the commands to familiarise yourself with.

1. mkdir
2. git init
3. git remote add origin
4. git push origin master

mkdir name-you-will-give-repo

Mkdir = make directory. Give a name to the repo you want to create. In my case…

mkdir pigs-can-fly

YOU DO NOT need to do this step if you already have a file or project started that you want to add.

Once created, you will then need to transform the repository into a git repository. Going a bit gangster we put ‘git in it’. Type the command.

git init

Then you run through the chain of command mentioned at the beginning. Status, add and commit (exactly as before). The ‘push’ part is slightly different here.

git remote add origin "url of repo created in GitHub"

This command is basically saying, ‘go to GitHub and add the origin file at this URL. After this your files on your computer will now be connected with the repo on GitHub.

git push -u origin master

This is the last command, push. Slightly different than before because you have to specify where you are pushing to. In this case, you are pushing to the master branch of your repo. Repos can have many different branches, but when you have just created a repo it will always default to add it to the master branch.

[NOTE these last two steps mentioned only need to be performed once in the initial setup of a repo. Once you have synced your files with GitHub, you then revert back to the chain of command as highlighted at the beginning.]

4 Adding files with terminal.

This is really simple.

1. touch

Using the touch command we can create any file within our repo without having to leave terminal. If I want to make an index.html file I type this command.

touch index.html

You can then do an ‘ls’ command to see the file you just created. You can create any file, for example, stylesheet.css, README file and even a .gitignore.

5 Final conclusions.

Now it is fully possible within some text-editors to have GitHub integration. I use Atom and within that, I can use a few shortcut keys to instantly add, commit and push my changes to GitHub. I never need to open terminal. The package is called Git-plus.

I would however strongly recommend that you get used to using terminal, especially if you are serious about back-end dev.

To keep this piece really simple, which was the aim, I have omitted merging, forking, and conflicts within repos. I have also not explained the .gitignore files.

To be honest at an early stage when just beginning with GitHub you are unlikely to need anything more advanced than this.

Resources.

Finally, you should check out this youtube series. Probably the best, most concise introduction to terminal I have come across. It really is very good.

Another youtube based tutorial — more user-friendly, but longer, is by Travis Neilson at DevTips. His series on GitHub is solid.

This article is also very well written. Setting up a repo from local to Github.

All the best everyone and I will see you again next Sunday.

Join us on Facebook & Slack.

Terminal & GitHub — Let’s make it REALLY simple! was originally published in Career Change Coders on Medium, where people are continuing the conversation by highlighting and responding to this story.