Learning from toddlers & should you program like Newton or Shakespeare?

#todayilearned #beginners #career #programming

TL;DR notes from articles I read today.

A meta-learning - observing children can teach us a lot.
When trying a new framework, tool or language, we need to play around and ask for help when we get stuck. Exploring is important.
When her toys get broken, we use the glue to fix them but once broken, they have a tendency of breaking again after some days. Even if they stay intact, she knows it is broken and at the risk of breaking again. Some code, like broken toys, cannot be repaired and the part or functionality needs to be completely replaced or rewritten.
She likes to play a game of spotting patterns. We tried to spot heart patterns one day. She was focused on finding those patterns everywhere and she won, of course. If we focus, we might discover patterns and principles that can help us solve problems. There are always patterns that we miss because we are not really looking for them.

Full post here, 4 mins read

The short answer is both. The longer answer is:

Just like when solving a math problem, you need to decompose a programming problem into smaller problems.
The presence of functions, binary & hexadecimal numbers, Boolean logic, and big O notation for analyzing algorithm performance are either actual math or very close to it.
Abstractions are useful not only when constructing programs but also when reasoning about programs. Reasoning precisely about abstractions takes a nod from maths.
Your code needs to communicate the structure and organization of the program to other programmers. You need a good overall structure and you need to divide your programs into smaller snippets, just like paragraphs, for better readability.
Programming is a repetitive process of coding with frequent refactoring/revising, much like editing to revise and improve the written text.

Full post here, 4 mins read

Here are a few key lessons I learned from this post:

If you’re interested in a new role, make sure you tell the right people about it in 1:1 conversations. Ask for advice and mentorship for the skills required for the role you want to be in.
Get to know yourself and what you like best. Learn as much as you can about aspects other than engineering, like product, design, compliance, support, sales, technical writing, etc.
Think about what you like & dislike in your current role and how those aspects would change if you moved to a different one.
Understand the aspects of the new role that you know little about and figure out how you can get more exposure to them.

Full post here, 9 mins read

DEV Community