4 ms·

>> don't want to know how the system works internally. > I see this sentiment a lot. I like that sentiment a lot. We have finite time and finite brain cycles.

>> don't want to know how the system works internally. > I see this sentiment a lot. I like that sentiment a lot. We have finite time and finite brain cycles. Stand proudly on others' shoulders and build something bigger. There's no shame in programming in high level languages to deliver more value more quickly. Ditto with operations, ditto with everything.

nicholassmith 14y ago
And there's no shame in standing on other peoples shoulders, but if you're building a web application you really need to think about having at least person with a devops background. Hell, even if they know how to compile from source and monitor properly that'd put them in a good place to go forward.
- cbsmith 14y ago
  It's great to stand on the shoulders of others, but you ought to be able to look down without getting lost.
flatline3 14y ago
> There's no shame in programming in high level languages to deliver more value more quickly. Ditto with operations, ditto with everything. There is shame in not understanding how that high-level language actually works, because it means you'll invariably be a worse programmer than the guy that does understand what he's actually doing.
seiji 14y ago
I think it's the difference between a user and an engineer. As a user, you... use. You don't care how it works. You drive a car; you don't design a car. Things get fuzzier in software development. Programmers are supposed to be users of everything they aren't programming. Things are supposed to be black boxes with fully isolated layers of abstraction. Ha. Doesn't work. To be competent, you must be aware of, at a minimum, what pieces are under you, at an intermedium, how they work, and at a maximum, how to create them yourself. I'm only talking about people who want to be great technical workers though. If you just want to make a MVP to get funding then hire dweebs, who wasted their life learning computers, to make you rich, feel free to do that instead.
- Retric 14y ago
  Have you taken an electron microscope to trace each line for every CPU you use in production to know how it actually works? No? Well perhaps, not needing to dig into how things work is a useful feature of a well designed system.
  - gummadi 14y ago
    How many software systems are even 1% as battle tested as a "CPU"? Even the most well designed software system doesn't have the kind of test coverage of a hardware.
    - Retric 14y ago
      CPU's are complex and far from perfect, often shipping with hundreds of 'errata' at the design level plus a wide assortment of random manufacturing errors in each chip. So, there is software that has fewer bugs and better coverage than a modern CPU. ex: Grep EX: Pages 19-73 with 2 to 4 errata per page for a single popular CPU design: http://download.intel.com/design/processor/specupdt/320836.pdf http://download.intel.com/design/processor/specupdt/320836.p... And that's just limited to stuff Intel knows about.
cbsmith 14y ago
> There's no shame in programming in high level languages to deliver more value more quickly. Ditto with operations, ditto with everything. Agreed. That isn't the same as the "don't want to know how the system works" mentality. High level languages are great tools for "encoding and automating processes you understand so you Don't Repeat Yourself, or perhaps Don't Need To Do It The First Time". They are great for "making all the initial decisions for you so you can get started and come back to those later". They are horrid tools for "allowing you to be ignorant". Now, I don't think everyone should know everything about computer systems (heck, just asking someone to know everything about C++ is a tall order ;-), and I certainly don't think you should have memorized all the configuration logic for hardware and software. However, if you are a technology professional, you really should see a key part of your professional value as your understanding of as much of how the system functions as possible. The understanding will never be total; it will never be complete; it ought to be an area of concern. If it isn't, you aren't an technology professional. You might be an entrepreneur. You might even be a great product designer. You aren't an engineer. That might sound like it is about semantics. It isn't. Computer systems are basically towers of babel where each brick is another leaky abstraction. Engineers are the people who build, maintain, and replace that tower. You can't do the job well if you only know about the roof. Entrepreneurs have such a huge challenge just searching for a viable business model, that they tend to see all other problems as irrelevant. While the problems are usually smaller, possibly even trivial by comparison, they aren't irrelevant. If you are a tech company, doing technology right is more than just a tiny bit relevant. Think of it this way: SQL provides a tremendously high level of abstraction to data systems. This makes it terribly efficient for quickly coming up with queries you want answers for. However, if something ever goes wrong, or if you are writing application code that is going to be run over and over again, you want someone who understands a lot more about the system than just how to translate a question in to SQL. That goes double if somehow the query is vital to your business' ongoing operations.
peterwwillis 14y ago
This is not a question of emotions. If you don't know how something works you won't be able to use it as well. If that's fine with you, okay. If you want to drive a race car, you don't have to be a mechanic. You do have to understand some basic physics and simple parts of the car. For example, when you turn sharply into a corner, the wheel's camber helps determine how much of the tire's surface stays on the road, giving you more grip, keeping you in the corner at a higher G-force. Looking at the wear on the tire you can tell that your camber might need to be adjusted, and that might make 1/10th of a second difference, which is the difference between winning and losing. If you want to program like a grandmother driving to the grocery store, all you need is gas. But if you want to program like a race car driver, try to learn how the internals work. I'd also add that if you want to program for people like Google or Amazon, you need to understand how the internals work, or you will be seriously embarrassed at the interview. (From personal experience)

nicholassmith 14y ago

And there's no shame in standing on other peoples shoulders, but if you're building a web application you really need to think about having at least person with a devops background. Hell, even if they know how to compile from source and monitor properly that'd put them in a good place to go forward.

cbsmith 14y ago
It's great to stand on the shoulders of others, but you ought to be able to look down without getting lost.

flatline3 14y ago

> There's no shame in programming in high level languages to deliver more value more quickly. Ditto with operations, ditto with everything. There is shame in not understanding how that high-level language actually works, because it means you'll invariably be a worse programmer than the guy that does understand what he's actually doing.

seiji 14y ago

I think it's the difference between a user and an engineer. As a user, you... use. You don't care how it works. You drive a car; you don't design a car. Things get fuzzier in software development. Programmers are supposed to be users of everything they aren't programming. Things are supposed to be black boxes with fully isolated layers of abstraction. Ha. Doesn't work. To be competent, you must be aware of, at a minimum, what pieces are under you, at an intermedium, how they work, and at a maximum, how to create them yourself. I'm only talking about people who want to be great technical workers though. If you just want to make a MVP to get funding then hire dweebs, who wasted their life learning computers, to make you rich, feel free to do that instead.

Retric 14y ago
Have you taken an electron microscope to trace each line for every CPU you use in production to know how it actually works? No? Well perhaps, not needing to dig into how things work is a useful feature of a well designed system.
- gummadi 14y ago
  How many software systems are even 1% as battle tested as a "CPU"? Even the most well designed software system doesn't have the kind of test coverage of a hardware.
  - Retric 14y ago
    CPU's are complex and far from perfect, often shipping with hundreds of 'errata' at the design level plus a wide assortment of random manufacturing errors in each chip. So, there is software that has fewer bugs and better coverage than a modern CPU. ex: Grep EX: Pages 19-73 with 2 to 4 errata per page for a single popular CPU design: http://download.intel.com/design/processor/specupdt/320836.pdf http://download.intel.com/design/processor/specupdt/320836.p... And that's just limited to stuff Intel knows about.

cbsmith 14y ago

> There's no shame in programming in high level languages to deliver more value more quickly. Ditto with operations, ditto with everything. Agreed. That isn't the same as the "don't want to know how the system works" mentality. High level languages are great tools for "encoding and automating processes you understand so you Don't Repeat Yourself, or perhaps Don't Need To Do It The First Time". They are great for "making all the initial decisions for you so you can get started and come back to those later". They are horrid tools for "allowing you to be ignorant". Now, I don't think everyone should know everything about computer systems (heck, just asking someone to know everything about C++ is a tall order ;-), and I certainly don't think you should have memorized all the configuration logic for hardware and software. However, if you are a technology professional, you really should see a key part of your professional value as your understanding of as much of how the system functions as possible. The understanding will never be total; it will never be complete; it ought to be an area of concern. If it isn't, you aren't an technology professional. You might be an entrepreneur. You might even be a great product designer. You aren't an engineer. That might sound like it is about semantics. It isn't. Computer systems are basically towers of babel where each brick is another leaky abstraction. Engineers are the people who build, maintain, and replace that tower. You can't do the job well if you only know about the roof. Entrepreneurs have such a huge challenge just searching for a viable business model, that they tend to see all other problems as irrelevant. While the problems are usually smaller, possibly even trivial by comparison, they aren't irrelevant. If you are a tech company, doing technology right is more than just a tiny bit relevant. Think of it this way: SQL provides a tremendously high level of abstraction to data systems. This makes it terribly efficient for quickly coming up with queries you want answers for. However, if something ever goes wrong, or if you are writing application code that is going to be run over and over again, you want someone who understands a lot more about the system than just how to translate a question in to SQL. That goes double if somehow the query is vital to your business' ongoing operations.

peterwwillis 14y ago

This is not a question of emotions. If you don't know how something works you won't be able to use it as well. If that's fine with you, okay. If you want to drive a race car, you don't have to be a mechanic. You do have to understand some basic physics and simple parts of the car. For example, when you turn sharply into a corner, the wheel's camber helps determine how much of the tire's surface stays on the road, giving you more grip, keeping you in the corner at a higher G-force. Looking at the wear on the tire you can tell that your camber might need to be adjusted, and that might make 1/10th of a second difference, which is the difference between winning and losing. If you want to program like a grandmother driving to the grocery store, all you need is gas. But if you want to program like a race car driver, try to learn how the internals work. I'd also add that if you want to program for people like Google or Amazon, you need to understand how the internals work, or you will be seriously embarrassed at the interview. (From personal experience)