“Is there a better way to achieve the goal I have in mind?”
“What decisions have been made?”
“Are those decisions relevant for the product I'm working on now?”
Something I don't think a lot of new coders are taught soon enough is that there is more than one way to get passing code, and more than one way to approach a problem.
Sure there are ways that are just ugly, or brute-force, or are re-covering old ground. But also some of the new technologies or experiments do exactly the same things as old ones, in new ways. That can be interesting to find out about, and pay dividends as a coder.
As an example one piece of my software stores a history of objects, and attached metadata.
Technically it can store anything, but others have solutions I can use and don't have to spend as much effort developing or maintaining.
The software it integrates with stores it's main DB in an RDBMS. To stop loading that system up with edge-case data or things we don't need an RDBMS for (separate documents, anything non-set based), it uses a separate storage for history and non-searchable data.
That same metadata service is used for prototyping. You send data in and get data out trivially compared to an SQL store or something more robust.
It doesn't make a lot of decisions, just "Have I got data?", oh I'll store {X} in {Y} (directly addressable vs searchable). You'd be surprised to know how fast it is to say store {X}, in {Y}, get {value} from {key}, than given {A,B,C,D,E,F,G} find me {X}, check if it exists, etc (what most CRUD systems do).
When we have context for decisions of system design, or data-structures we can make smarter choices. We're able to composite ideas that others have pre-verified to make a new cool thing that helps solve problems for people, feel good about ourselves, get paid & get things done!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Need to add to that list of
Something I don't think a lot of new coders are taught soon enough is that there is more than one way to get passing code, and more than one way to approach a problem.
Sure there are ways that are just ugly, or brute-force, or are re-covering old ground. But also some of the new technologies or experiments do exactly the same things as old ones, in new ways. That can be interesting to find out about, and pay dividends as a coder.
As an example one piece of my software stores a history of objects, and attached metadata.
Technically it can store anything, but others have solutions I can use and don't have to spend as much effort developing or maintaining.
The software it integrates with stores it's main DB in an RDBMS. To stop loading that system up with edge-case data or things we don't need an RDBMS for (separate documents, anything non-set based), it uses a separate storage for history and non-searchable data.
That same metadata service is used for prototyping. You send data in and get data out trivially compared to an SQL store or something more robust.
It doesn't make a lot of decisions, just "Have I got data?", oh I'll store {X} in {Y} (directly addressable vs searchable). You'd be surprised to know how fast it is to say store {X}, in {Y}, get {value} from {key}, than given {A,B,C,D,E,F,G} find me {X}, check if it exists, etc (what most CRUD systems do).
When we have context for decisions of system design, or data-structures we can make smarter choices. We're able to composite ideas that others have pre-verified to make a new cool thing that helps solve problems for people, feel good about ourselves, get paid & get things done!