Welcome to Read: 01
Pre-Work - Code 401: Advanced Javascript Development
In this Read: 01, I will talk about those topics:
- How to Solve Programming Problems.
- Become 100x More Productive.
- How to think like a programmer — lessons in problem solving.
- 5 Whys.
How to Solve Programming Problems
When most programmers are given a programming problem in an interview, they make several key mistakes. The most severe of those is the improper allocation of time.
If you have heard the saying “measure twice and cut once,” then you are probably familiar with the idea of spending upfront time to make sure something is done right, rather than diving right in.
-
You must resist this urge.
The most common mistake I see when conducting interviews or watching someone try to solve a programming problem is they try to start writing code as soon as possible.
You really want to make sure you take enough time to understand the problem completely before attempting to solve it. -
A simple set of steps
- Read the problem completely twice.
- Solve the problem manually with 3 sets of sample data.
- Optimize the manual steps.
- Write the manual steps as comments or pseudo-code.
- Replace the comments or pseudo-code with real code.
- Optimize the real code.
for further inforamtion please click here
Become 100x More Productive
You have very few hours here on on this earth.
Still, many people waste much of their time on pointless, low-quality activities that don’t help them reach their true goals — their mission.
The truth is, most people value their time at far, far less than it’s worth.
They say yes to things they have no business doing. They give away their talents, attention, and effort to others who take, take, take.
They spend hours watching low-quality television and social media when they should be productive and effective.
-
“Busyness” Isn’t a Badge of Honor; It’s a Sign of Weakness
It takes discipline to not become “busy.” If you let it, your world and the people around you will take all your time.
Your time is not unlike your paycheck; if you don’t budget for things, you’ll have nothing left over by the end of the month.
This is how lives are wasted — by doing thankless work for ungrateful takers that didn’t deserve your time in the first place. -
Busyness and Stress Are the Enemy
Most people prize “being busy.” They proclaim it with pride, as if it’s a badge of honor.
But for most people, this “busyness” is nothing more than distraction and procrastination from what really matters. They just like feeling busy.
For world-class performers, busyness and stress are the enemy. They’re a sign you’re off-track. It means you’ve been lazy and undisciplined, and have let too many unimportant tasks take you away from what really matters.
for further inforamtion please click here
How to think like a programmer — lessons in problem solving
Problem solving is the meta-skill. We all have problems. Big and small. How we deal with them is sometimes, well…pretty random.
The 4-Hour Chef
- Understand
- Know exactly what is being asked. Most hard problems are hard because you don’t understand them (hence why this is the first step).
- Plan
- Don’t dive right into solving without a plan (and somehow hope you can muddle your way through). Plan your solution!
- Divide
- Pay attention. This is the most important step of all.
- Stuck?
- Debug: Go step by step through your solution trying to find where you went wrong. Programmers call this debugging (in fact, this is all a debugger does).
- Reassess: Take a step back. Look at the problem from another perspective. Is there anything that can be abstracted to a more general approach?
- Research: Ahh, good ol’ Google. You read that right. No matter what problem you have, someone has probably solved it. Find that person/ solution. In fact, do this even if you solved the problem! (You can learn a lot from other people’s solutions).
for further inforamtion please click here
5 Whys
Have you ever had a problem that refused to go away? No matter what you did, sooner or later it would return, perhaps in another form.
Stubborn or recurrent problems are often symptoms of deeper issues. “Quick fixes” may seem convenient, but they often solve only the surface issues and waste resources that could otherwise be used to tackle the real cause.
How to Use the 5 Whys
- Assemble a Team
- Gather together people who are familiar with the specifics of the problem, and with the process that you’re trying to fix.
- Define the Problem
- If you can, observe the problem in action. Discuss it with your team and write a brief, clear problem statement that you all agree on.
- Ask the First “Why?”
- Ask your team why the problem is occurring. (For example, “Why isn’t Team A meeting its response time targets?”) Asking “Why?” sounds simple, but answering it requires serious thought. Search for answers that are grounded in fact: they must be accounts of things that have actually happened, not guesses at what might have happened.
- Ask “Why?” Four More Times
- For each of the answers that you generated in Step 3, ask four further “whys” in succession. Each time, frame the question in response to the answer you’ve just recorded.
- Know When to Stop
- You’ll know that you’ve revealed the root cause of the problem when asking “why” produces no more useful responses, and you can go no further. An appropriate counter-measure or process change should then become evident.
- Address the Root Cause(s)
- Now that you’ve identified at least one root cause, you need to discuss and agree on the counter-measures that will prevent the problem from recurring.
- Monitor Your Measures
- Keep a close watch on how effectively your counter-measures eliminate or minimize the initial problem. You may need to amend them, or replace them entirely. If this happens, it’s a good idea to repeat the 5 Whys process to ensure that you’ve identified the correct root cause.
for further inforamtion please click here
| Read | Title | ToGo |
|---|---|---|
| Read: 01 | Pre-Work - Code 401: Advanced Javascript Development |  |
| Read: 02 | Readings: Express | |
| Read: 03 | Readings: Express REST API | |
| Read: 04 | Readings: Data Modeling | |
| Read: 06 | Readings: Authentication | |
| Read: 07 | Reading: Bearer Authorization | |
| Read: 08 | Reading: Access Control (ACL) | |
| Read: 09 | Reading: OAuth 2 | |
| Read: 11 | Readings: Event Driven Applications | |
| Read: 12 | Readings: Socket.io | |
| Read: 13 | Readings: Message Queues | |
| Read: 14 | Readings: Event Driven Architecture | |
| Read: 16 | Readings: AWS: Cloud Servers | |
| Read: 17 | Readings: AWS: S3 and Lambda | |
| Read: 18 | Readings: AWS: API, Dynamo and Lambda | |
| Read: 18 | Readings: AWS: Events | |
| Read: 26 | Reading: Component Based UI | |
| Read: 27 | Reading: Props and State | |
| Read: 28 | Readings: Component Composition | |
| Read: 29 | Readings: Routing | |
| Read: 31 | Reading: Hooks API | |
| Read: 32 | Reading: Custom Hooks | |
| Read: 33 | Reading: Context API | |
| Read: 34 | Reading: <Login /> and <Auth /> |
|
| Read: 36 | Reading: Application State with Redux | |
| Read: 37 | Readings: Redux - Combined Reducers | |
| Read: 38 | Readings: Redux - Asynchronous Actions | |
| Read: 39 | Readings: Redux - Additional Topics | |