Do the important shit first.

I guess this may be more of a project management thing, but trying to figure out what the most important part of a task is, and getting that done first.

If I’m cleaning the bathroom, I do the sink, because if I have to stop, that’s typically the grossest part.

When I’m doing my taxes, I do the stupid parts that I can’t afford to get wrong first.

When I’m packing for a trip, I get the stuff I need day-to-day sorted out and in my carry-on.

I don’t think these are great examples, but they mean something to me.

Often when I’m working on some code, all my errors are because of something much different than what the error message is telling me. I’ve learned that often, most problems have a different cause and better solution.

I’m good at breaking down problems into small chunks and not getting overwhelmed by a big project. Do I have the motivation to finish these tasks? That’s a different question.

That things like tests, inline comments, and READMEs are helpful notes to my future self.

Breaking down problems in smaller pieces you can solve / reason about so they don’t feel overwhelming. This is a very good life skill as well.

using regex to find the absolute value of a number:
$number =~ s/-//;

using regex to check if a number is odd:
print “odd!\n” if (($number / 2) =~ /\./)

…and generally _abusing regex for weird stuff it wasn’t intended for, because the regex engine is surprisingly efficient.

🌼 Just PERLy Things! 🌼

Appreciating possible failures (pessimism, some call it) and being methodical, even if it’s tediously methodical.

Interestingly, the notion that switch statements can require a default is reflective of the truth to the idea that when the stakes get high, we all fall back to our default level of training or function. This has global applications to our functionality and, by extension, the inputs (things,people/their methods,contexts) in our lives as well

wat

1. Simplify problems before trying to solve them.

2. Generalizable solutions are better than ones that aren’t.

One thinking skill Ive picked up from programming is to really take all the time necessary to articulate a thought using the best words.

Clear communication is worth the time and effort. Using the right word for each concept, learning new words as necessary, makes a positive impact on all the uses of that communication.

So if you have ever dealt with PLCs beyond the basics you know that timing/parallelism is a clusterfuck of misery and pain until you get to the point where you can master it.

I am pretty decent at keeping multiple things going as a result.

When I start a personal project I create a readme file that has a ToDo section and a Change Log section. Anything I think of that I might want to do I put under ToDo, break it into small chunks and prioritize it. When a task is completed under the ToDo section, I move it to the Change Log section. Easy to maintain, track progress, and documents both a Road Map and Changes all in one place. It also has a section for references to shared assets that need attribution. Actually to keep it simple the same document usually also has an about section, an installation section, and a usage section.

No matter how you do, there are always other efficient ways.

You might be interested in the book Algorithms to Live By. It’s not a masterpiece or crazy deep, but it’s a pretty accessible look at a few applications of CS approaches to real world problems.

Some parts in math in high school got easier.

Loops and recursion or just thinking iteratively in general. If you get this, then mathematical induction gets much more intuitive if you’re studying math.