Harley Ferguson’s Post

To become a better developer: → Understand the problem → Identify potential solutions → Choose the best possible solution → Then only start writing the code to solve the problem Don't waste time writing code before you've actually got a plan in place. Your time is precious, so use it wisely.

Every software developer knows that complexity is the enemy of completion. Here are 3 steps to help you Simplify Complex tasks into manageable Chunks: 📚 Understand The Core Problem to Create your Main Tasks Start by understanding the core problem that you are trying to solve. If you don´t understand the problem, work for a better understanding. Then, Categorize and outline your main tasks. 💻 Create Small Test Applications to Prepare for Task Breakdown Uncertainty in breaking down tasks suggests insufficient prior knowledge. To better understand the effort needed to solve main tasks, create small test applications to familiarize yourself with APIs or libraries. 🪓 Break Down The Main Task Into Chunks Now it’s time to start breaking down the complexity. Start focusing on one main task at a time. Write a step-by-step bullet point on how you would implement it. Go through the tasks again and again until you are satisfied with the size Breaking up the complexity into smaller tasks is all about helping you to simplify the understanding of the problem. This helps you and your team to stay motivated by having a clear picture of the implementation. See the full article here: https://lnkd.in/dGXhkvPf Read this post and more on my Typeshare Social Blog: https://lnkd.in/d48_h-e5

Why most developers fail: - Read the problem - Immediately write code - Get stuck - Research solutions - Research more solutions - Write code - Delete all code - Reread the problem - Ask for assistance How successful developers operate: - Understand the problem - Research solutions - Plan the chosen solution - Write code to solve problem - Ask for assistance - Optimize Don't complicate things by writing code before you understand the problem.

One of the most frustrating parts of coding interviews is knowing that you're being judged by people with superstitious beliefs about them. Writing code early is the way that some people accomplish Harley's suggested step 1: understand the problem. Sometimes drawing a diagram is helpful. Sometimes plotting a graph is helpful. Sometimes writing out some math is helpful. And sometimes, it's helpful to type out some wrong code that you later delete. Harley should understand it as a valid way of trying to represent the problem, like a diagram, on the path to ultimately understanding it. Instead, he interprets it as a "failed" attempt and a signal of a lack of competence. I used to teach computation-based 1st year physics. Some students were more comfortable starting with the math representations of the problem and others were more comfortable starting with the code representations of the problem. Different folks, different strokes. > Don't complicate things by writing code before you understand the problem In the real world, I invite you to start writing code before you've understood the problem. It may be helpful to read it, run it, and see how it fails. It can be easily deleted and changed as your understanding improves. In job interviews, good luck navigating the constellation of weird, unwritten rules that you're being judged by.

And this is the trick I use to improve my codebase. No videos. No tutorials. No articles will explicitly tell you on how to manage your codebase effectively. You would have to identify it by yourself! And this is only possible by exploring the codebase of other developers. Yes, it's simple but not as simple as you might think! 1): Take an hour out of your (“busy”) week 2): Search for projects on GitHub & Bitbucket 3): Dive deep into their folder structure 4): Check their code writing principles 5): Note down the new best practices you discover 6): And lastly, implement them in your next project because we learn by doing Once you have the codebase that the market demands, then the ball is in your court. P.S. Don’t forget to appreciate the developer whose codebase helped you in any way. P.P.S. Do you share your code openly?

from the book Ask your developer: share problems, not Solutions with your developers.

How most developers fail: - Read the problem - Immediately start writing code - Get stuck - Research solutions - Research more solutions - Write code - Delete all code - Reread the problem - Ask for assistance How successful developers operate: - Understand the problem  - Breaking down the problem into smaller parts  - Research solutions - identify the right approach - Write code to solve problem - Ask for assistance - Optimize Don’t rush into writing the code before you fully understand the problem!

#30daysofcodingReactJSChallenge Day 4 In today's post, I want to simplify some of the terminologies I have used in passing thus far. I know I have gurus in my tribe here, so please if there be any terminology you are confused about, the comment section is yours truly Terminologies: 1. Fragment (<>...</>): In React, a fragment is a way to group multiple JSX elements together without adding an extra DOM element. It's like a lightweight wrapper that doesn't render any additional HTML. Benefits of Fragments: No Unnecessary wrapper elements, No Extra DOM Nodes, Improved Readability 2. State (Statefulness and statelessness): State refers to the condition or status of a system or component at a particular point in time. A system or component is considered stateful if it retains the state or status of previous interactions or requests while a system or component is considered stateless if it does not retain any state or status information between interactions or requests. Simply: Statefulness: Remembering past interactions. Statelessness: Treating each interaction independently. 3. Modularity: Modularity in software development refers to the practice of breaking down a software system into smaller, independent, and interchangeable modules or components. These modules are designed to be self-contained, encapsulating specific functionality, and can be easily combined to build complex systems. This is why the react component system promotes modularity. 4. XML (Extensible Markup Language): It is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It is very similar to HTML because they make use of the same syntax. The major difference is in the purpose, xml is designed for storing and transporting data, rather than displaying data on web pages I hope you can go over my previous post and have a better understanding of its content. See you in the next post. I am Akinola Emmanuel A software developer and fintech enthusiast.

Stop being indispensable! As a developer, your role is to solve problems using digital products that will run without you. To be a good developer, you always need to consider that you won’t be there anymore one day. Your code needs to be readable by someone else. They should be able to discover the features you implemented just by reading your code. Your code needs to be maintainable by someone else. They should be able to debug your code without reading the whole application source code. Your code needs to be scalable by someone else. They should be able to add new features without rewriting the whole application. There are practices to improve these factors. But they are often forgotten. It is the main reason of the very popular total code revamps v2, v3, etc. If you follow these practices, you won’t need to recreate new versions of your product from scratch. So stop writing your code like you were indispensable!

Do you ever find yourself stuck in overthinking mode as a developer? You're not alone. In this short video, I share 3 tips that I personally use and they've never failed me .