I’m glad you found it helpful! And no, I love my current job, but I appreciate the sentiment!

To add onto this, sometimes it’s about getting more specific with your questions to get the more specific answers.

For context of how I would suggest structuring these detail questions, here’s how I think about code I write or debug: The functions and classes my code is made of are meant to get specific inputs to become specific outputs via a defined process; I think of this as inputs->how->outputs. Figuring out what inputs you need to execute the “how” part to get the outputs you want is the puzzle of each function or class I write. The “how” part can even be broken down further into smaller chunks of inputs->how->outputs.

I think asking your engineer friends to frame things in this context would both show your appreciation for the nitty-gritty details you are needing, as well as give you further context to ask more detailed drill-down questions (about deeper levels of inputs->how-> outputs) if needed. For example: “you said to get inputs A and B to result in output C, we need to run the fizzbuzz algorithm on A and B. What roles do those inputs have in that algo? Do we have to do any preprocessing on A or B before we fizzbuzz them, or any post processing of the fizzbuzz’s direct output to get C?” “Oh, yeah, we have a wrapper that takes A and makes it column-major so that fizzbuzz executes faster, but we need output C to be row-major for when it goes into otherFunction(), so we do such-and-such to fizzbuzz’s output to get the C we output.” This gets you a level of detail deeper, and you could ask further questions about the transformations happening to A and the post-processing of fizzbuzz output to get C, as well as get more context for otherFunction to ask more about later.

You could also use this context to ask further questions about what they think the future implementation should look like. “Are there any assumptions we can make about A and B or how C is used that could simplify how we go from the former to the latter? Are there any requirements on the inputs and outputs that would better be either relaxed or made more stringent, and if so, in what way?”

I hope that helps! Best wishes for your work on this project–streamlining processes is hard, especially when working with other people’s code, but your appreciation for the details to get things implemented well is admirable!

The oddest I’ve ever encountered: EXACTLY 15 characters long. No more, no fewer. 15.

Honorable mention: Various online accounts where I used my password manager to generate a long, secure password, which the website accepted without warning or error. I was then locked out because their user management system could not handle such long passwords (had to create a second account with a much shorter password to find that out) 🤣

This is a great analogy! To build on these points and the analogy: I like to think of my coding in terms of inputs, outputs, and what needs to happen to the inputs to get the outputs I want: that is, inputs->how->outputs. So for this buttered toast analogy, your inputs would be:

• toaster
• electricity
• bread
• butter
• knife
• plate
• operator’s hands

The desired output: toasted bread on the plate with butter spread on one side.

The “how” is the sequence of specific instructions the instructor gives to the operator.

This approach is even more helpful as you start working on larger projects; as you think about a problem you’re trying to solve, try to break the overall input->how->output into smaller modules of input->how->output, and then you can use those modules (often called “functions” or “methods”) in the overall “how.” Let’s say you want the instructor and operator to prepare a full breakfast with bacon, eggs, and buttered toast. You’ll have some more inputs, of course (frying pan, raw bacon, shelled eggs, stove, in addition to the toast components), but since you already made a known-good make_buttered_toast function, you can incorporate that function into the pipeline to go from your more comprehensive set of inputs to the full breakfast outputs, and you can make separate functions for making the bacon and making the eggs. Finally, your overall program can then call your bacon, eggs, and toast functions to result in the desired output of a full breakfast.

Now here’s where breaking the problem down into smaller input->how->output chunks really comes in handy: one day, you are tweaking your breakfast-making code, and suddenly, your overall outputs have good bacon and good toast, but the eggs wind up dumped half-cooked on the stove. But since you made nice, modularized functions for toast, bacon, and eggs, you automatically know more where to start looking for the bug: the eggs function.

There’s a lot of good advice in the responses to this post! Overall, I just wanted to emphasize what I wish I had learned much earlier on in my career: the benefits of thinking in terms of inputs->how->outputs and modularizing sub-problems in the overall program’s “how” into subproblems that can be independently considered, debugged, and re-used on future projects. (A secret for you: those of us who have been coding for a while often don’t start everything from scratch–we’ll re-use some functions or classes we wrote in the past, tweaking them as necessary for new applications, but not needing to start from a blank text editor :) ) Learning to write applications in code is exploring a new way of thinking about problems and how to solve them, and personally, I find it very rewarding!

I wish you all the best on your coding journey!