How do you think about code? Does it change whether it’s for a fun personal project or for work? Whether cruising through the deliverables or stuck for days debugging? Or in your free time when the lines of code swirl in your mind?
Is it a friend or foe? Is it just ones and zeroes forever dancing on a screen? Perhaps it’s just fancy words setup in fancy way that magically does fancy stuff?
Not too get to far from the idea, but simply thinking about how you think about code is great way to self improve, especially in the problem solving part of programming. Like most things in life, truly understanding a situation comes from being able to take multiple perspectives.
Data Structures and Algorithms has been one of the funnest and most dreadful parts of my programming experience. In essence, they tend to be logic problems, riddles that require being able to think around corners.
Programming methodology, generally revolves around first making it work, then better, then making it look clean. Is this always the best way?
To get back to DS&A, following this methodology implies that best way to solve a DS&A problem is brute force. Maybe that is the answer for some smaller scoped problems, but most DS&A problems need to run a lot of data and brute force can mean creating a solution that requires dozens or hundreds of steps that can really be refactored to a handful.
The idea here is that all programming, by inclusion DS&A, is based on hard logic. Pure, cold math. So do exactly that! Find the independent variables, the dependent variables, and the conditionals. Make sure to include the constraints! Then fit these into equations based off each other that only work based on the variables! Draw diagrams and charts that help you visualize the data or possible scenarios.
The best case here is that you math and logical reasoning is strong enough that you can find an optimal solution quickly! Worst case is that you’re back where you started. This worst case never really happens because trying these new perspectives means you will learn something new about the problem that you didn’t know before.
That just means you’re closer to the solution that you were at the beginning.
In essence, these tips aren’t just useful to DS&A but to most programming (and life) problems. Maybe these processes won’t work for you, but it’s more important to expand your toolset because the bigger the shed is, the wider the range of solutions you can create.
Alejandro's blog 