4 ms·

It sounds like you're just getting started, so I would say: pay attention to the "seams" between layers/modules/components/machines/etc. Especially these days w

It sounds like you're just getting started, so I would say: pay attention to the "seams" between layers/modules/components/machines/etc. Especially these days when we are building higher and higher abstractions, you will understand a lot better if you examine how things interface with each other. You will learn more deeply & more correctly, and it's a great way to debug problems. For instance: Find out how to make your ORM log the SQL it's running, and try running that in your database directly. If you are having trouble, get the SQL working first, and then figure out how to make your ORM generate that SQL. On the web, use View Source and/or Inspect Element to see what is really in the DOM. Look at the Javascript you're serving. Is it what you think it should be? Maybe the problem is in your webpack config or caching or something. If SCSS is giving you trouble, look at the CSS it's generating. Is it what you expect? If there is a problem submitting a form, look at the Network tab to verify the right things are being sent. Understand how HTTP works here. Try putting the same request into `curl -v`. (Browsers even have a "Copy as cUrl" command nowadays.) If that looks okay, see if Rails is turning your submitting into the right params (or whatever your framework is). One nice thing about checking the seams is you can debug via binary search: first see if the problem is in the browser or the server. Next see if it's in your app or the database. Next see if it's in your controller or your model. Etc.

bennylope 8y ago
> If you are having trouble, get the SQL working first, and then figure out how to make your ORM generate that SQL. This, specifically, is very good advice: using the ORM as a tool to implement a SQL-first solution. And not just good advice for beginners.
- C1sc0cat 8y ago
  Why use an ORM.
desc 8y ago
This. Visibility into what is actually going on, and the drive to understand it. Troubleshooting, debugging, learning: all the same thing, but tarred with different parts of the process. Dig into what's actually going on and understand the layer under you. tl;dr: Keep digging, because everything's worth knowing at some point. It's generally much easier to fix a bug in your own code or infrastructure if you're familiar with the innards of the things you depend upon directly, and learning your preferred platform beneath the current frameworks is a solid advantage because it helps you move sideways when the next New Framework comes along. But there's also the conceptual side, the general concepts which have remained unchanged for decades, which a detailed knowledge of a specific platform (eg. Java, .NET, Node.js) doesn't necessarily aid with. These probably won't even feel relevant on a daily basis, but will definitely multiply your effectiveness over the long term. Some things which might fall into that category: * SQL and relational databases (especially if you're not using SQL, because you'll be reinventing it for any nontrivial amount of data) * Consistency models and distributed systems (capabilities and limitations; some things can never be waved away by technology) * The operating system, and principles of its design (not necessarily in any great detail, but knowing roughly how software talks to hardware is very useful, especially when assessing the marketing blurb for any cloud platform) * Complexity theory (stringing three 'optimal' algorithms together might be textbook, but often you can apply some domain knowledge to cut out a step or two to reduce actual runtime and maintenance overhead) I've found stuff like graph theory, principles of compiler design, and a working knowledge of assembly code to be useful too, but that's probably the far end of the bell curve for web server stuff :P Computer Science is a subset of mathematics and it's amazing which bits of pure maths turn out to be useful in my day job. Shame I'm not very good at that stuff... but reading enough about it to recognise when it's applicable can mean the difference between 'picking a good library off the shelf' and 'hacking together a terrible solution myself'.
flukus 8y ago
Inspecting the DOM, client side javascript and generated CSS are all front end concerns, not stuff for back end development, even if many of us do both. > Find out how to make your ORM log the SQL it's running, and try running that in your database directly. If you are having trouble, get the SQL working first, and then figure out how to make your ORM generate that SQL. Time would be much better spent learning SQL properly. ORM's have their place, they can cut down a tonne of boilerplate, but anyone using an ORM should be somewhat competent in SQL already. If you learn SQL from ORM output then in many cases you'll be learning what not to do.

bennylope 8y ago

> If you are having trouble, get the SQL working first, and then figure out how to make your ORM generate that SQL. This, specifically, is very good advice: using the ORM as a tool to implement a SQL-first solution. And not just good advice for beginners.

C1sc0cat 8y ago
Why use an ORM.

desc 8y ago

This. Visibility into what is actually going on, and the drive to understand it. Troubleshooting, debugging, learning: all the same thing, but tarred with different parts of the process. Dig into what's actually going on and understand the layer under you. tl;dr: Keep digging, because everything's worth knowing at some point. It's generally much easier to fix a bug in your own code or infrastructure if you're familiar with the innards of the things you depend upon directly, and learning your preferred platform beneath the current frameworks is a solid advantage because it helps you move sideways when the next New Framework comes along. But there's also the conceptual side, the general concepts which have remained unchanged for decades, which a detailed knowledge of a specific platform (eg. Java, .NET, Node.js) doesn't necessarily aid with. These probably won't even feel relevant on a daily basis, but will definitely multiply your effectiveness over the long term. Some things which might fall into that category: * SQL and relational databases (especially if you're not using SQL, because you'll be reinventing it for any nontrivial amount of data) * Consistency models and distributed systems (capabilities and limitations; some things can never be waved away by technology) * The operating system, and principles of its design (not necessarily in any great detail, but knowing roughly how software talks to hardware is very useful, especially when assessing the marketing blurb for any cloud platform) * Complexity theory (stringing three 'optimal' algorithms together might be textbook, but often you can apply some domain knowledge to cut out a step or two to reduce actual runtime and maintenance overhead) I've found stuff like graph theory, principles of compiler design, and a working knowledge of assembly code to be useful too, but that's probably the far end of the bell curve for web server stuff :P Computer Science is a subset of mathematics and it's amazing which bits of pure maths turn out to be useful in my day job. Shame I'm not very good at that stuff... but reading enough about it to recognise when it's applicable can mean the difference between 'picking a good library off the shelf' and 'hacking together a terrible solution myself'.

flukus 8y ago

Inspecting the DOM, client side javascript and generated CSS are all front end concerns, not stuff for back end development, even if many of us do both. > Find out how to make your ORM log the SQL it's running, and try running that in your database directly. If you are having trouble, get the SQL working first, and then figure out how to make your ORM generate that SQL. Time would be much better spent learning SQL properly. ORM's have their place, they can cut down a tonne of boilerplate, but anyone using an ORM should be somewhat competent in SQL already. If you learn SQL from ORM output then in many cases you'll be learning what not to do.