This is a quite personal question. Feel free to point me elsewhere if you think this does not fit the overall discussion happening here, or if there are solution exists for the exact same problem.

Most of the time, My coding skill allows me to modify the code in the most generally understandable higher-level language, even in one that I have no experience with while producing some simple script-like creation, but that's it, nothing more. I currently lack the proper training to produce a solution-level product. Or, else to say, I can translate from human language instructions to code and back (Likewise, I have a pretty good grip on translating), but I was never able to write them myself.

I do understand that there is software engineering knowledge that I lack, such as data structure, algorithms, and design patterns. Still, based on my dotted learning over the years, even if I managed to learn them, I do not have the mindset to transfer the knowledge that I owned to the project I intend to make.

I'm not quite sure where my learning path goes wrong. Most classes for completely newbies on the market too focused on the usage of a particular tool (like a language or a framework), which I could quickly follow without learning anything. Abstract-based courses are more focused on explaining what is the thing rather than how to use it. Project-based learning doesn't do much to me, since the same: the simple one does not require a creative mind, thus does nothing to my growth, the hard one requires too much of a creative mind, thus I can't even finish.

This flawed mind now harms my other reach in STEM. I know perfectly well how most of the things work in human language, I can do well above the average with instructions, I can calculate perfectly based on a given model, but I cannot transfer the understanding to the model, transfer the model to the required equation or experimentation, which is critical for the things I wish to do but can't.

So, with all these lengthy explanations of my problem presented, I'm asking for help. Do you have dealt with a similar problem, or do you have friends or families having success with similar problems? I would be grateful for any kind of consecutive response. If not on my general learning disabilities, then first the CS part. What knowledge do I need to persist solidly for a successful solution prototype? For those pieces of knowledge, what are your best recommendations for learning resources?

New to LessWrong?

New Answer
New Comment

2 Answers sorted by

Viliam

Apr 09, 2024

20

A specific example (maybe two or three examples of a different kind) could help a lot: what you wanted to do, what do did, where you got stuck.

Trying to remember my early experience, at school people typically some math-like problems, something like "calculate a square root of X using an interpolation method, also check for incorrect inputs" that would basically be one function (or one library in a more complex case) in the program. You either do not program the user interface, or it is something very obvious.

And then the real life is something like: "so, we have been writing these things on paper, and we wonder whether there is a smarter way to do that, like with a computer", and the space of possible solutions is just so wide you don't even know where to start... and you suspect that the part where you actually calculate the square root will probably be less than 1% of the entire code. And you have no guidance how to do the remaining 99%.

*

My first advice would be to do a prototype first. Some horribly low-status solution with zero security, just to have a specific example where you can check whether everyone is even talking about the same thing. (Otherwise you risk working hard on a solution that no one actually wants.) When the prototype is ready, tested, and approved, then you can build the actual thing. Or maybe you won't need to.

Many things can actually be done using a spreadsheet. The advantage is, you usually don't have to teach people how to use a spreadsheet. You also get functionality like online cooperation, access rights, and using the solution from the smartphone for free. (Yeah, online cooperation can lead to editing conflicts. Don't worry, this is a prototype. If you need a dynamic number of lines, use 100; increase to 1000 when needed.) From the developer's perspective, updating a spreadsheet is much easier than updating an application -- and you will need to update it a lot, because customers usually talk before they think.

If you work for a small customer (an individual or a small NGO), spreadsheet or some Python script is probably what they need. If you work for a large corporation, they probably have a list of technologies you are supposed to use (you will probably have to integrate with whatever they use for authentication, logging, etc.).

Thanks for the advice, but as I've replied in the comments part, I'm now exactly stuck on the "build the actual thing" stage. I knew bodging around would be productive for most of the tasks, but I feel I may not gain real personal growth by just doing this.

FlorianH

Apr 09, 2024

20

If I understand you correctly, what you describe seems a bit atypical, or at least not similar in all other people, indeed.

Fwiw, pure speculation: Maybe you learned very much from working on/examining advanced/codes type codes. So you learned to understand advanced concepts etc. But you mostly learned to code on the basis of already existing code/solutions.

Often, instead, when we systematically learn to code, we may learn bit by bit indeed from the most simple examples, and we don't just learn to understand them, but - a bit like when starting to learn basic math - we constantly are challenged to put the next element learned directly into practice, on our own. This ensures we master all that knowledge in a highly active way, rather than only  passively.

This seems to suggest there's a mechanistically simple yet potentially tedious path, for you to learn to more actively create solutions from scratch: Force yourself to start with the simplest things to code actively, from scratch, without looking at the solution first. Just start with a simple problem that 'needs a solution' and implement it. Gradually increase to more complexity. I guess it might require a lot of such training. No clue whether there's anything better.

I'm relatively accustomed to this style of learning when building skills. But not minds. For example, I can't think of a way I'll accustom myself to practicing design patterns towards a fictional task, rather than do it in the dirtiest way possible in plain procedural. Yes, most learning material would include an example, but other than following the author's thinking while knowing that "I'm learning this thing so the answer is that", I can't use the learned pattern when dealing with real tasks.

More than not I would use a checklist to measure whether my cr... (read more)

3 comments, sorted by Click to highlight new comments since: Today at 6:58 AM

Hi!

Why do you think the problem you are talking about is specific to you and not for everyone?

Without more details, the described problem looks like a common problem for everyone: most people struggle to formalize their thoughts (and programming is a formalization). No one can translate their knowledge into code without mistakes. People make mistakes; it is okay.

Are you comparing yourself to someone else? Or to some "ideal" image of "how you should work"?

Maybe you could provide more concrete examples of your problem, like "I need to do X, but I struggle here and here and make mistakes here and here."

"Personal" in "Describing myself without fitting in the possible category" fashion. Not really mean that I'm atypical, in fact, I do wish my problems were typical to an extent so that I would have credible guides in resolving this problem.

I'll have an example that I personally experienced recently, omitting some details related to my PII.

Coding: I'm relatively familiar with data processing using Python. Reading from Text/JSON/Spreadsheet, sanitizing, running query and analyze (using modules and sometimes even interacting with scaffold NN models), formatting results. Normally not over 300 lines, mostly just piecing sample codes gathered from documents, other projects, and IntelliSense. But when a temporary analysis pipeline becomes a production practice, I'm required to upgrade the whole thing to the production level: Procedural must be wrapped with OOP abstraction for calling from other parts; Sanitazion designed for static data becomes generic for various inputs; Procedure shall be equipped thread-safe and concurrency-safe; etc., which requires vast rewrite and even if I manage to achieve some of the goals, the change would often render other change unusable.

I would like to write library-level projects in a modern and well-designed fashion, and my daily tasks often contain the kind of job that would make this kind of perfection worthy, not just worthy, but even critical. But as I stated in the question body, I'm not able to orchestrate them all together.

>I'll have an example that I personally experienced recently, omitting some details related to my PII.

Based on this example, could you compare your expected outcome with the real outcome? In numbers. For example, "I expected to finish this refactoring in two weeks, but it took two months" or "I expected to finish this refactoring in two weeks, but my colleague completed the same task in two days." Something like that.

I have more than 15 years of experience in software development, not precisely in data processing but in gamedev and backend (and sometimes in data processing), which is pretty close.

From my experience, most people are struggling with the task you described. Even senior developers with 5-10 years of experience. I saw only a few people, who could do such refactoring naturally and from the first try.

I may suggest a few things:

- Try to reevaluate your expectations. Maybe you are too hard on yourself. You may overestimate the required result and try to do more than you need.
- Research a few methodologies of development. I may suggest Test Driven Development and Pair Programming. The first may help you control changes easier, and the second may help you learn how other people solve similar tasks.
- Try to pay more attention to code decomposition and structuring when you work on "pipeline prototype". Aka, add some "fake" functions/objects that will be required later, but for now, do nothing or contain trivial logic. Sometimes, it is easier to see what you need to do when you are fully in the task's context rather than when you are refactoring your code. 
- Do not try to implement all features at the same time. Choose one, implement it, cover it with some tests or types or both, and then move to another.