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.
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.