Phase 5, the last three-week unit of the software engineering program, is upon me! 12 weeks down. It's now solo project time then !bang...it's done.
Looking back, I would like to share some advice and insights that may help you navigate the course successfully.
Maintain Quiet, Balance and Perspective
First, make sure you have a quiet place to study with minimal distractions. A good pair of noise-cancelling headphones helps me to focus as well.
While spending gobs of hours in front of a screen appears noble, it's counterproductive. Far better to take regular, rejuvenating and relaxing breaks. Your body will thank you from your eyes to your derriere (excuse my French) and your back to your feet -- I have had many an eye-strain headache and sore bottom from not taking breaks or mixing up standing with sitting.
If you need reminders to take breaks, use a cool pomodoro gizmo like the one below or use your laptop/desktop/watch/phone's built-in timer features to set time intervals.
Ready ✔️, Set ✔️ Go!
You will have a structured day that begins with a morning cohort meeting followed by self-study of homework labs in the target languages(There are a lot of labs. My advice, follow your cohort leader's instructions on how to effectively approach them). Also, realize that the labs sometimes show clunky ways to solve a solution followed by a better way as a progression in order for you to develop a thought process that aids in your critical thinking/problem solving skills.
A one-hour lunch follows (don't eat a heavy meal! food coma onset...), then there is a 90-minute to 2-hr lecture covering important concepts that starts the afternoon portion of the school day. Even if you don't cover all of the labs, try to read the content-based assignments and watch the videos leading up to the lectures so you have an idea of where the lecturer is going and what they are doing.
Most lecturers do not recommend coding along. I second that. The live lectures will be uploaded for later review. Concentrate on active listening and take good notes (each lecture has a Google doc that provides a place to take notes, but take notes however you like). You can code along later if you replay the video as a way to review, which might be more effective.
With large cohorts, it's tempting to compare yourself with others. Don't! Compare===Despair. Measure your ability to grasp the necessary concepts for the particular learning unit you are in, not yourself with others. I've seen even the trailblazer students get bogged down on a solution. So, everyone hits barriers and has struggles. Seek help after a half-hour of genuine effort to solve a problem. Google the problem. Ask your fellow cohort mates, too, and of course, your instructors. I have found everyone to be very helpful.
Practice & Review Regularly
Usually, the Thursday(sometimes it could be on a Wed or Friday depending upon holidays, etc) of each 2nd week in a phase is a code challenge. They will have 3 or 4 practice code challenges that you should do --space them out over a period of time rather than doing them all at once-- Additionally, a mock code challenge released a day or two before the actual challenge is also given followed by your instructors working out the challenge solution later that day. Take careful note of how they go about tackling the problem systematically. You don't have to find the solution exactly the way they do, but their thought process and breaking down the problems into more manageable chunks could be a goldmine of wisdom for you.
It is important that you not try to match a coding pattern and apply it to every challenge. Why? Well, like a broken clock, at the most it will be right two times in the day but wrong all of the other times. Drilling down and understanding the fundamental concepts the unit teaches is the way to go. Apply that knowledge to the challenge rather than parrot a pattern that sometimes works but you don't really know why.
In addition to this, another effective learning tool is knowing how to test your code to see if it's doing what you want it to do. Do you know how to console.log() something or use the browser's built in developer tools to check for errors or bugs? Learn how to use them. You will learn a lot this way.
https://techdevblog.io/the-console-chronicles-your-guide-to-debugging-mastery/
https://coderpad.io/blog/development/javascript-debugging-in-chrome/
Undoubtedly, with repetition certain things will develop that "muscle memory." You no longer need a step-by-step guide to tie your shoe laces because you've done it thousands of times. Some things will come with unconscious effort while others you will find require you to still look up documentation again and again. But, if you've added reference skills as a normal part of your practice routine you'll likely find your solution.
Git going
Starting in week three of Phase 1 through Phase 4, you'll be paired with a cohort mate to come up with a project. For the rest of your coding life you will be using Git and Github. So, learn it early and become a master.
What are they and what's the difference? I offer this definition from W3Schools:
What is Git?
Git is a popular version control system. It was created by Linus Torvalds in 2005, and has been maintained by Junio Hamano since then.
It is used for:
Tracking code changes
Tracking who made changes
Coding collaboration
What does Git do?
- Manage projects with Repositories
- Clone a project to work on a local copy
- Control and track changes with Staging and Committing
- Branch and Merge to allow for work on different parts and versions of a project
- Pull the latest version of the project to a local copy
- Push local updates to the main project
Working with Git
- Initialize Git on a folder, making it a Repository
- Git now creates a hidden folder to keep track of changes in that folder
- When a file is changed, added or deleted, it is considered modified
- You select the modified files you want to Stage
- The Staged files are Committed, which prompts Git to store a permanent snapshot of the files
- Git allows you to see the full history of every commit.
- You can revert back to any previous commit.
- Git does not store a separate copy of every file in every commit, but keeps track of changes made in each commit!
Why Git?
- Over 70% of developers use Git!
- Developers can work together from anywhere in the world.
- Developers can see the full history of the project.
- Developers can revert to earlier versions of a project.
What is GitHub?
- Git is not the same as GitHub.
- GitHub makes tools that use Git.
- GitHub is the largest host of source code in the world, and has been owned by Microsoft since 2018.
Here's a helpful tutorial for starting off your first pair project to set up your collaboration:
(https://medium.com/@keilalofra/pair-programming-a-github-guide-1d57ca1b5370)
Happy coding!
Top comments (0)