pull down to refresh

I feel like this is an important area that differentiates newer devs from experienced ones. How do you deal with the unknown? A new problem? A problem with complexities and multiple moving parts?
I'm definitely still learning but when I'm faced with a tough coding task, I start by searching for the simplest example related to my problem on Google, StackOverflow, or through ChatGPT. I focus on fully understanding this basic example, breaking it down to grasp each part.
Next, I rebuild the example from the ground up. This helps me ensure I know why each piece is there and how it works. It's not just about copying code; it's about learning and understanding the foundation.
After getting the basics right, I begin adding complexity—introducing new features and refining the project step by step. This phase involves a lot of trial and error, learning from mistakes, and gradually improving my understanding and the project's sophistication.
I also keep asking for help, utilizing sn, nostr, and my friends here in pleblab.
What's your strategy for handling challenging coding tasks?
Very similar approach in my academic research. By definition, i need to tackle problems that have never been tackled before. As least, for the big picture. For the small parts that make up the problem, it's easy to find examples on how to tackle those. Learn from those and implement it to my context. It's then a matter of putting things together and filling up the holes.
reply
I would like to answer this in great detail, but don't have time at the moment. This is a question I often get (in one form or another) from more junior engineers on my various teams. It's hard to answer concretely, but I will try my best.
@remindme in 1 day
Does that work yet?
reply
670 sats \ 1 reply \ @k00b 20 Feb
Work on getting the smallest, simplest part of the problem done then go from there.
When you’re doing hard things, you need to feel like you can and will make progress or you’ll be paralyzed. You need a story about the progress you’ve made and what the result of more effort will be. As of now, I’ll call this The Hard Story. I think every person doing hard things has The Hard Story, it’s unique to them, and their story is ultimately what motivates and defeats them (should they tell themselves the wrong story). The story starts the moment you begin making progress.
reply
I should clarify "by go from there" I work on the next smallest, simplest part and so on. Tasks or projects are scenes in The Hard Story and each is a hard story in itself. It's a recursive narrative.
When you're not out of your league on a problem, sometimes you'll go after the more complex parts of the problem first because you'll be bored by the small and simple ones.
reply
197 sats \ 0 replies \ @Atreus 21 Feb
All I'll say is that, if you ever have kids—and you should—be sure to teach them early on that it's okay to crash and burn 🔥 every now and then. It's definitely not ideal, but there's more shame in not trying.
reply
To reiterate much of what you said, a complex problem can usually be broken down into discreet blocks with each block being simple to fully grasp. Decomposing the complexity often reveals a much simpler structure that can be reassembled into a system that provides the same desired outcome, but in a more understandable and logical way. As an example, when you see "spaghetti code", there is typically a poorly designed data structure that requires complex code to "fix" the underlying issue. It is much better to have a good data model and bad code, than a bad data model and great code.
reply
Never had that feeling of having to do something out of my league if its a complex feature it's not a problem, if it's a very technical thing that someone wants in a specific way, then I research on chatgpt, github to see how some libraries or frameworks do the same thing and I also ask opinion of my coworkers that have the same or more experience.
reply
Debug and google until it works.....or I get bored.
reply
I don't. Zero to prove.
reply
10 sats \ 1 reply \ @k00b 20 Feb
Do we only do hard things when we have something to prove?
reply
Usually, unless it's practical, then you just grind away until its done.
reply