3 ms·

What about money doesn't matter to a company? Why should you isolate an engineer from that as though it doesn't matter? As an electrical engineer, we scrounge

What about money doesn't matter to a company? Why should you isolate an engineer from that as though it doesn't matter? As an electrical engineer, we scrounged for every cent on devices when they were being released. A TVS diode can be replaced with a capacitor? That's a cent. A cheaper processor? Several tens of cents. Over ten million devices plus the legacy of your design into the next generations, that's a lot of money. Someone else negotiates the price of the TVS diode and the processor, but that doesn't mean you should be isolated from the cost. A thing that does X and is more expensive is worse than a thing that does X cheaply. Software engineers spend fractional cents on requests executed thousands of times per second. That's the same scale as the electrical engineering example when you do this. As far as I can tell, most good software engineers are very cost aware. That doesn't mean they don't do stuff. They just understand the cost of that stuff. This does seem to be a big divide between senior and junior engineers, as well.

bongodongobob 2y ago
> Why should you isolate an engineer from that as though it doesn't matter? Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. Their job is to come up with the best design using common sense when it comes to cost. Cost of a part isn't the only thing that matters either. Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. The engineers engineer and the bean counters count beans. They meet and find a happy place. Why would you even want that extra workload? The fact that you think it's so easy just goes to show why actual accountants do the accounting, managers do the managing, procurement does the procuring, and operations does the operating. "I know calculus, accounting is easy!" Sure, if you throw out all of the variables other than unit cost.
- Panzer04 2y ago
  This seems insane to me. It's not that hard to have a ballpark awareness of how much things cost. You need accountants etc because you need to ensure that all of the little things are done, not so that everyone else in the business can be unaware of the business case for their product. Yes, you shouldn't care about lot sizes and cost breaks (unless they are significant deciding factors), but knowing that one operation is going to cost 2x another, largely equivalent operation is relvant/important.
  - pclmulqdq 2y ago
    Exactly, there is no "engineering" separate from the beans. Anyone can make a bridge that stands. It takes an engineer to make one that barely stands. The same largely goes for computer systems.
    - kijin 2y ago
      When the economy is booming and there's a lot of money sloshing around, developers can get away with shrugging and saying "not my problem" to things like cloud costs and energy efficiency. Those same developers don't get to complain on the rainy day, when someone who knows how to save the company millions of dollars a year gets a better deal.
    - Retric 2y ago
      Engineer’s don’t build bridges that barely stand up, they have a huge margin at completion. Instead they build bridges based on some agreed upon lifespan.
      - pclmulqdq 2y ago
        They do make the cheapest thing counting that margin. Immediately past that margin of safety, your bridge will fall down. In other words, given an expected load of 10 tons and a 50 year lifetime (as you mentioned), an engineer will try to design the cheapest possible bridge that holds 50 tons (5x load) and will last 70 years.
        Retric 2y ago
        Being able to handle 50 tons at year 70 may be well over 200 tons at year 1, which is a hell of a lot more than a simple 5x margin.
        pclmulqdq 2y ago
        Sure. Pick a specified load at a specified time and the engineer's job is to build the cheapest possible bridge at that load and time. Raising the safety factor doesn't change the objective function. The objective function is still "cheapest within spec." This is why bridges are not just huge chunks of titanium. Those would work very well at handling 50 tons at year 70, but would be shitty bridges because they are too expensive to build.
- pclmulqdq 2y ago
  > Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. It is your job, when you make something, to understand how it works. How much it costs to operate is an integral part of how it works. > Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. A 10x larger lot size makes each part per unit cheaper and it simplifies production to eliminate items from your BoM. Understanding that sort of thing in an order-of-magnitude sense is also part of your job. By the way, you don't need to know this stuff precisely to make good decisions. You need to know it roughly. You still need to know it, though.
  - kube-system 2y ago
    But business process cost is often not part of a software engineers job, or at least, many do not see it as one. I have often seen software engineers spend days or weeks building something that can be purchased off the shelf for less than a couple hundred dollars.
- dotancohen 2y ago
  > The engineers engineer and the bean counters count beans. They meet and find a happy place. I'd say that the engineers never initiate contact with the bean counters, and the bean counters very very rarely initiate contact with the engineers.
doix 2y ago
The "problem" with software is that the margins are "too high", so companies _usually_ don't care. The general attitude I've encountered is that the engineering salary dominates the cost, so it's usually not worth spending time optimizing runtime costs. This is eventually taken to the extreme and you occasionally see posts here titled something like "how we saved millions by doing X", where the thing they were originally doing was extremely wasteful. For the last decade, we've also been in a "free money" mode. Where companies were happy to spend money as long as it led to growth. Optimizing for cost wasn't a priority. That has leaked into electrical engineering as well. There were a few products that shipped full Raspberry pis in an enclosure in the name of velocity. The savings possible there were probably in the dollars, not cents, not to mention the supply chain issues. And yet companies did it in the name of velocity.
- carlmr 2y ago
  >There were a few products that shipped full Raspberry pis in an enclosure in the name of velocity. The savings possible there were probably in the dollars, not cents, not to mention the supply chain issues. And yet companies did it in the name of velocity. Sometimes it's better to have a product that you can sell, than waiting to perfect the product to sell. Let's leave aside the RPi availability issues, you could do this with any other discovery board. Say you want to sell your first 1000 of products x, y, and z to see how the product market fit is. You might find that x and y don't sell at all, but z was sold out in the blink of an eye. Now you can design a custom PCB for z, knowing that it will probably sell well. And until that is finished you continue selling the off the shelf version. Some profit is better than no profit, and consistency is good for your brand.
kortilla 2y ago
The time you spent scrounging for cheaper parts needs to be compared to the opportunity cost and the actual production scale. Software engineers, especially at startups, are building proofs of concept that they need to iterate on very quickly. Spending significant thought on reducing opex is an absolutely terrible call in the early stages of dev. If you have a profitable product, or one that would be if you can squeeze costs, then you play the optimization game. The difference between electrical engineering and software engineering is that software can be updated after it’s deployed. The ability to get all of those gains later changes the strategy completely
- pclmulqdq 2y ago
  > Software engineers at startups, are building proofs... I fixed that one for you. Software engineers not at startups are usually not building proofs-of-concept. They are usually building production systems. And at the early stages of development of production systems, it can save a lot of headache down the road to think ahead. Yes, you will be slower in the moment, but the number of times I have heard a startup say "we did great with our first version, but then realized we needed to completely rewrite the thing to scale" (when the rewrite takes literally a week longer than the first version) has been too high.
  - kortilla 2y ago
    >They are usually building production systems. This is completely false. Most startups go through massive pivots. I’ve been through 6 of them (2 successful exits) and literally everyone made drastic changes to every code base to target completely different markets and features. I’m telling you from experience, if you can’t recognize providing business value as an engineer recognizing opportunity cost, you will stagnate as a junior engineer or even destroy the company as a senior one.
    - pclmulqdq 2y ago
      Most software engineers don't work at startups.
rramadass 2y ago
You are very right. Good Hardware/Software Engineers are cost aware at some appropriate level which may not be the detailed bean-counter level. For example, I used to interact with Marketing/Sales folks to get some data on unit cost, sales targets etc. which i then used as motivation to better focus on prioritizing features and time frames. Nothing clears your mind of irrelevant data then knowing what exactly matters as the bottom-line for a company.
stcroixx 2y ago
Many software companies spend money like they have no care in the world. Inflated salaries and all kinds of silly perks. Feels pointless to care about saving them money when they're going to hire Beyonce to be at the holiday party.

bongodongobob 2y ago

> Why should you isolate an engineer from that as though it doesn't matter? Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. Their job is to come up with the best design using common sense when it comes to cost. Cost of a part isn't the only thing that matters either. Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. The engineers engineer and the bean counters count beans. They meet and find a happy place. Why would you even want that extra workload? The fact that you think it's so easy just goes to show why actual accountants do the accounting, managers do the managing, procurement does the procuring, and operations does the operating. "I know calculus, accounting is easy!" Sure, if you throw out all of the variables other than unit cost.

Panzer04 2y ago
This seems insane to me. It's not that hard to have a ballpark awareness of how much things cost. You need accountants etc because you need to ensure that all of the little things are done, not so that everyone else in the business can be unaware of the business case for their product. Yes, you shouldn't care about lot sizes and cost breaks (unless they are significant deciding factors), but knowing that one operation is going to cost 2x another, largely equivalent operation is relvant/important.
- pclmulqdq 2y ago
  Exactly, there is no "engineering" separate from the beans. Anyone can make a bridge that stands. It takes an engineer to make one that barely stands. The same largely goes for computer systems.
  - kijin 2y ago
    When the economy is booming and there's a lot of money sloshing around, developers can get away with shrugging and saying "not my problem" to things like cloud costs and energy efficiency. Those same developers don't get to complain on the rainy day, when someone who knows how to save the company millions of dollars a year gets a better deal.
  - Retric 2y ago
    Engineer’s don’t build bridges that barely stand up, they have a huge margin at completion. Instead they build bridges based on some agreed upon lifespan.
    - pclmulqdq 2y ago
      They do make the cheapest thing counting that margin. Immediately past that margin of safety, your bridge will fall down. In other words, given an expected load of 10 tons and a 50 year lifetime (as you mentioned), an engineer will try to design the cheapest possible bridge that holds 50 tons (5x load) and will last 70 years.
      - Retric 2y ago
        Being able to handle 50 tons at year 70 may be well over 200 tons at year 1, which is a hell of a lot more than a simple 5x margin.
        pclmulqdq 2y ago
        Sure. Pick a specified load at a specified time and the engineer's job is to build the cheapest possible bridge at that load and time. Raising the safety factor doesn't change the objective function. The objective function is still "cheapest within spec." This is why bridges are not just huge chunks of titanium. Those would work very well at handling 50 tons at year 70, but would be shitty bridges because they are too expensive to build.
pclmulqdq 2y ago
> Because it's not their job and therefore they don't have the information necessary to know what is or isn't expensive. It is your job, when you make something, to understand how it works. How much it costs to operate is an integral part of how it works. > Ok, we can save 1 cent if we swap this part out. But now we have to purchase lot sizes that are 10x bigger. How does that impact production? How does that affect operational budgets? Etc. A 10x larger lot size makes each part per unit cheaper and it simplifies production to eliminate items from your BoM. Understanding that sort of thing in an order-of-magnitude sense is also part of your job. By the way, you don't need to know this stuff precisely to make good decisions. You need to know it roughly. You still need to know it, though.
- kube-system 2y ago
  But business process cost is often not part of a software engineers job, or at least, many do not see it as one. I have often seen software engineers spend days or weeks building something that can be purchased off the shelf for less than a couple hundred dollars.
dotancohen 2y ago
> The engineers engineer and the bean counters count beans. They meet and find a happy place. I'd say that the engineers never initiate contact with the bean counters, and the bean counters very very rarely initiate contact with the engineers.

doix 2y ago

The "problem" with software is that the margins are "too high", so companies _usually_ don't care. The general attitude I've encountered is that the engineering salary dominates the cost, so it's usually not worth spending time optimizing runtime costs. This is eventually taken to the extreme and you occasionally see posts here titled something like "how we saved millions by doing X", where the thing they were originally doing was extremely wasteful. For the last decade, we've also been in a "free money" mode. Where companies were happy to spend money as long as it led to growth. Optimizing for cost wasn't a priority. That has leaked into electrical engineering as well. There were a few products that shipped full Raspberry pis in an enclosure in the name of velocity. The savings possible there were probably in the dollars, not cents, not to mention the supply chain issues. And yet companies did it in the name of velocity.

carlmr 2y ago
>There were a few products that shipped full Raspberry pis in an enclosure in the name of velocity. The savings possible there were probably in the dollars, not cents, not to mention the supply chain issues. And yet companies did it in the name of velocity. Sometimes it's better to have a product that you can sell, than waiting to perfect the product to sell. Let's leave aside the RPi availability issues, you could do this with any other discovery board. Say you want to sell your first 1000 of products x, y, and z to see how the product market fit is. You might find that x and y don't sell at all, but z was sold out in the blink of an eye. Now you can design a custom PCB for z, knowing that it will probably sell well. And until that is finished you continue selling the off the shelf version. Some profit is better than no profit, and consistency is good for your brand.

kortilla 2y ago

The time you spent scrounging for cheaper parts needs to be compared to the opportunity cost and the actual production scale. Software engineers, especially at startups, are building proofs of concept that they need to iterate on very quickly. Spending significant thought on reducing opex is an absolutely terrible call in the early stages of dev. If you have a profitable product, or one that would be if you can squeeze costs, then you play the optimization game. The difference between electrical engineering and software engineering is that software can be updated after it’s deployed. The ability to get all of those gains later changes the strategy completely

pclmulqdq 2y ago
> Software engineers at startups, are building proofs... I fixed that one for you. Software engineers not at startups are usually not building proofs-of-concept. They are usually building production systems. And at the early stages of development of production systems, it can save a lot of headache down the road to think ahead. Yes, you will be slower in the moment, but the number of times I have heard a startup say "we did great with our first version, but then realized we needed to completely rewrite the thing to scale" (when the rewrite takes literally a week longer than the first version) has been too high.
- kortilla 2y ago
  >They are usually building production systems. This is completely false. Most startups go through massive pivots. I’ve been through 6 of them (2 successful exits) and literally everyone made drastic changes to every code base to target completely different markets and features. I’m telling you from experience, if you can’t recognize providing business value as an engineer recognizing opportunity cost, you will stagnate as a junior engineer or even destroy the company as a senior one.
  - pclmulqdq 2y ago
    Most software engineers don't work at startups.

rramadass 2y ago

You are very right. Good Hardware/Software Engineers are cost aware at some appropriate level which may not be the detailed bean-counter level. For example, I used to interact with Marketing/Sales folks to get some data on unit cost, sales targets etc. which i then used as motivation to better focus on prioritizing features and time frames. Nothing clears your mind of irrelevant data then knowing what exactly matters as the bottom-line for a company.

stcroixx 2y ago

Many software companies spend money like they have no care in the world. Inflated salaries and all kinds of silly perks. Feels pointless to care about saving them money when they're going to hire Beyonce to be at the holiday party.