Cover image for How to be outcome driven while learning to code or at work?

How to be outcome driven while learning to code or at work?

jcsmileyjr profile image JC Smiley ・2 min read

I asked my local tech community this question: “How can I be outcome driven while learning how to code or at work?”

The following is a curated list of their fantastic answers!!!

Corey McCarty
Bullet Journaling is the best way that I know. Handle your tasks like you handle coding. Identify the primary goal, break it into smaller tasks systematically until they are clear to you what will be done. Then start working on those tasks. At any point, if you find yourself spending more time than expected on a task then you should ask yourself what is the desired outcome. You may find that you are spending time on one option that has become more difficult than another option that you had previously ruled out.

Start with the job search. Find a few jobs that you want. Identify which languages, frameworks, and experience you need. Make your learning plan focused on those goals. Don’t start with HTML, CSS, and JavaScript until you found a few jobs that you want to do in your area that require those. You might just find that Java is all you need to land that first job.

Autumn Ragland
I like to keep a list of weekly and monthly goals that I can look back on regularly to keep me motivated!

JC Smiley
Set daily, weekly, and monthly goals that resonate with your personality and is aligned with the teams, company, or bosses goals.

When planning projects write out all the technologies or methodologies you already know and what new tech you plan on learning while building it. This way you know the outcome and how it will benefit you.

The same idea apply to planning your learning journey utilizing free resources or conferences. I use Trello and a calendar to keep up with future conference, videos I want to view, or resources in order of how they align with each other.

Dennis Kennetz
Assume every piece of code you write will be given to and used by someone else and you are the only point of contact for the product. This way people can ONLY ASK YOU if they have questions. If this was the case, you would not want your entire day interrupted by questions, so you would write clean code with easy to understand variable names and function descriptions / methods / classes. Your documentation would be excellent and you would have awesome unit tests in place that would cover edge cases as well as standard protocols. In the documentation you would clearly define how to compile and run, what the inputs are, and what the outputs will be.

Code Connector is a non-profit that's organized tech meetups to help people start their journey into tech. You can join our daily conversations by clicking this link: Code Connector slack channel.


Editor guide