3 ms·

Maybe I’m just not good enough at paying attention, but for me it seems like you have to actually run into problems over and over and figure out how to avoid th

Maybe I’m just not good enough at paying attention, but for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems. Then you end up being able to mentally simulate what problems you will run into, and design is basically all about avoiding future problems of various kinds (and balancing tradeoffs about which future problems to avoid and how much effort to put into each, whether you can solve multiple with one design play, etc).

teekert 1y ago
I have this too, I have never been able to "do exercises" or "study a codebase". I need to be making something that I am excited about, then I'll learn, from examples, from wanting to be thorough and correct. But sometimes I think I'm just not their yet, if I become able to read code like a book and really understand what happens, which often I don't, then perhaps I'll enjoy the process more.
- estimator7292 1y ago
  That's how I learn as well. I've found that reading code is a completely different thing from learning. Not even tangentially related. I can read a codebase and run simulations in my head. But this almost never results in learning anything. I can study code and see how a particular task is done, but I don't learn it until I put it into practice. Just about the only thing I get from reading other people's code is the most egregious ways to not do something. This is a pretty common thing, a plurality of humans learn this way. We just have different standards for software, for some reason. We like to pretend books teach you something more "real" than just getting your hands dirty and writing some real fucked up code. But the reality is that figuring out why your disaster code doesn't work, and then fixing it is one of the most educational experiences a programmer can have.
pixelworm 1y ago
This is pretty much how I've learned up to this point (and will of course continue). Trying to learn from real world code will be a new experience for me. Not sure how valuable it will be but should be fun either way.
globular-toast 1y ago
That's kinda like saying you can learn to drive by just getting into a car, crashing then thinking about how not to crash it next time. In reality both things are necessary. The car analogy doesn't hold for road driving because we drive well within the limits, but for racing it really is necessary to know exactly where the limits are. I don't think we should really be treating our profession like a race, though. But if you don't read it's going to be an incredibly long slow process and a lot of car crashes and mangled gearboxes etc. So I say read, read, and read some more. Even if you don't see the point of it right now your experience will later find a place for it and you won't end up descending a hill for the first time not knowing to shift to a lower gear.
- sim7c00 1y ago
  you mention a key point. profession. programmer doesnt really imply professional programmer. I'd aay if you do it for a living, certain tedious chores must be learned. the best programmers i know (professional) can all read code. they spent many junior years learning to read it, being on code auditing desk.... nowadays idk how the landscape looks, but for all of them they had to review and read code to find bugs before they were allowed to produce code (they all worked at same company ofc... so my view is limited!) i do feel such discipline is needed. they can always poke holes on my code no matter how many holes i plug :) - i am semi professional. i write code for work, but not production code. (experimental). i never learned to audit code and feel that makes it impossible for me to truly create production grade code
- ramesh31 1y ago
  >That's kinda like saying you can learn to drive by just getting into a car, crashing then thinking about how not to crash it next time. That would be a perfectly valid way of learning to drive if crashing had no danger or destruction and you could instantly reset the car every time. Software is a special case of engineering where the cost of failure is extremely low, so trial and error is generally the fastest way to get going with actually doing something.
  - globular-toast 1y ago
teiferer 1y ago
> for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems This shows how immature the field of software engineering is. Imagine bridges or houses were built like that. Or your surgeon was trained like that. Over time, we hopefully develop estblished norms, but at the moment, things are too much in flux. Put 5 sw engineers in a room, pose a problem and you will get not just 5 different solution proposals, but there will likely be strong disagreements on which approach is a good one. "I recognize a good solution when I see it" is just not good enough for a serious engineering discipline.
- hvb2 1y ago
  > Imagine bridges or houses were built like that. Or your surgeon was trained like that. While I don't disagree with you in general, this does feel a bit off. By that logic you can call the field of music immature, and all of the arts. I think the difference is that its easy to experiment without high costs. I genuinely think that if building bridges was cheap and quick, the fastest way to learn was to try...
  - nchagnet 1y ago
    I generally agree with your point on ease of experimentation, but if we insist on calling it software engineering, then maybe the field needs to adhere to engineering principles, as the GP highlighted.
    - tuckerman 1y ago
      I believe part of engineering isn’t over-engineering for the task at hand as well. If the costs of a “failure” are low/zero then the right thing can be to move quickly expecting some problems. I think the field could get better at knowing when costs are low (eg sometimes scalability, cheaper to change a database choice than rebuild a bridge) and where the costs are sometimes very high (eg security).
    - HPsquared 1y ago
      Notice OP says "software design". Design is still an art, even in mechanical engineering. Engineering applies to looking at a design and proving something about it.
chistev 1y ago
This is it
Breza 1y ago
I totally agree with you. Some of the most intense thinking I've put into writing code has been when I go out for a run in the middle of the day and come back 30 minutes later with solutions to the thing I spent all morning trying to fix.

teekert 1y ago

I have this too, I have never been able to "do exercises" or "study a codebase". I need to be making something that I am excited about, then I'll learn, from examples, from wanting to be thorough and correct. But sometimes I think I'm just not their yet, if I become able to read code like a book and really understand what happens, which often I don't, then perhaps I'll enjoy the process more.

estimator7292 1y ago
That's how I learn as well. I've found that reading code is a completely different thing from learning. Not even tangentially related. I can read a codebase and run simulations in my head. But this almost never results in learning anything. I can study code and see how a particular task is done, but I don't learn it until I put it into practice. Just about the only thing I get from reading other people's code is the most egregious ways to not do something. This is a pretty common thing, a plurality of humans learn this way. We just have different standards for software, for some reason. We like to pretend books teach you something more "real" than just getting your hands dirty and writing some real fucked up code. But the reality is that figuring out why your disaster code doesn't work, and then fixing it is one of the most educational experiences a programmer can have.

pixelworm 1y ago

This is pretty much how I've learned up to this point (and will of course continue). Trying to learn from real world code will be a new experience for me. Not sure how valuable it will be but should be fun either way.

globular-toast 1y ago

That's kinda like saying you can learn to drive by just getting into a car, crashing then thinking about how not to crash it next time. In reality both things are necessary. The car analogy doesn't hold for road driving because we drive well within the limits, but for racing it really is necessary to know exactly where the limits are. I don't think we should really be treating our profession like a race, though. But if you don't read it's going to be an incredibly long slow process and a lot of car crashes and mangled gearboxes etc. So I say read, read, and read some more. Even if you don't see the point of it right now your experience will later find a place for it and you won't end up descending a hill for the first time not knowing to shift to a lower gear.

sim7c00 1y ago
you mention a key point. profession. programmer doesnt really imply professional programmer. I'd aay if you do it for a living, certain tedious chores must be learned. the best programmers i know (professional) can all read code. they spent many junior years learning to read it, being on code auditing desk.... nowadays idk how the landscape looks, but for all of them they had to review and read code to find bugs before they were allowed to produce code (they all worked at same company ofc... so my view is limited!) i do feel such discipline is needed. they can always poke holes on my code no matter how many holes i plug :) - i am semi professional. i write code for work, but not production code. (experimental). i never learned to audit code and feel that makes it impossible for me to truly create production grade code
ramesh31 1y ago
>That's kinda like saying you can learn to drive by just getting into a car, crashing then thinking about how not to crash it next time. That would be a perfectly valid way of learning to drive if crashing had no danger or destruction and you could instantly reset the car every time. Software is a special case of engineering where the cost of failure is extremely low, so trial and error is generally the fastest way to get going with actually doing something.
- globular-toast 1y ago

teiferer 1y ago

> for me it seems like you have to actually run into problems over and over and figure out how to avoid the problems This shows how immature the field of software engineering is. Imagine bridges or houses were built like that. Or your surgeon was trained like that. Over time, we hopefully develop estblished norms, but at the moment, things are too much in flux. Put 5 sw engineers in a room, pose a problem and you will get not just 5 different solution proposals, but there will likely be strong disagreements on which approach is a good one. "I recognize a good solution when I see it" is just not good enough for a serious engineering discipline.

hvb2 1y ago
> Imagine bridges or houses were built like that. Or your surgeon was trained like that. While I don't disagree with you in general, this does feel a bit off. By that logic you can call the field of music immature, and all of the arts. I think the difference is that its easy to experiment without high costs. I genuinely think that if building bridges was cheap and quick, the fastest way to learn was to try...
- nchagnet 1y ago
  I generally agree with your point on ease of experimentation, but if we insist on calling it software engineering, then maybe the field needs to adhere to engineering principles, as the GP highlighted.
  - tuckerman 1y ago
    I believe part of engineering isn’t over-engineering for the task at hand as well. If the costs of a “failure” are low/zero then the right thing can be to move quickly expecting some problems. I think the field could get better at knowing when costs are low (eg sometimes scalability, cheaper to change a database choice than rebuild a bridge) and where the costs are sometimes very high (eg security).
  - HPsquared 1y ago
    Notice OP says "software design". Design is still an art, even in mechanical engineering. Engineering applies to looking at a design and proving something about it.

chistev 1y ago

This is it

Breza 1y ago

I totally agree with you. Some of the most intense thinking I've put into writing code has been when I go out for a run in the middle of the day and come back 30 minutes later with solutions to the thing I spent all morning trying to fix.