There is a commonly shared view in the programming community that algorithm puzzles are something you do to prep for an interview and than you never use in the actual job. This certainly rings true as in 15 years of programming, i feel I can count on fingers the number of times I needed to stop and think about data structure / algorithm, rather than usual workload of thinking about what's even the problem being solved; how to structure code; what's the interface at the module/service/package boundary; how to make code testable/maintainable/flexible etc… Iterating though a list or a dict is all ds/algo you'll need 99% of the time.

FF to now when I'm on a burnout induced sabbatical, and after a while I got itchy to write some code again. Problem was that all the ideas for projects I'd like to do are, well… projects. I still don't feel like digging through manuals for libraries and frameworks and writing boilerplate and doing all the things that need to be done to push things through. Anyhow, I was sitting in a coffee shop with my illustrator friend, who, at some point, just pulled out a notebook, spent 20-ish minutes drawing something that caught his eye and was like: "that's it for today". That's it… 20 minutes, it's done, tomorrow something else, new blank page… So I got into puzzles. Now, the first thing I do in the morning is solving a daily puzzle on leet code. If I feel like it, I might also do problems from an old competition. And I'm having a blast!

Which brings us to the question from the title: is there a direction I can push this forward? I mean, I don't mind this just being fun, but I was curious, is there something out there in the "Real World" that I'm missing that is closer to this kind of problem solving from what i was doing so far?

  • atheken@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    And you can do the previous years of the coding challenge at any time.

    I took some time off, and this was a good source of solving “real” problems, rather than trying to write something to optimize for l33tcode (which, is fine… just not a good measure for typical software engineering responsibilities, IMO).