3 ms·

This is a very common problem in many orgs. Spending time (adding meetings, exploring various options, etc.) is completely fine while spending money is a huge d

This is a very common problem in many orgs. Spending time (adding meetings, exploring various options, etc.) is completely fine while spending money is a huge deal because of the emotional connection to money that many people seem to have. Imagine, holding a 2 hour, 10 person meeting to decide if an additional one time $1000 cloud expenditure is warranted. Yet, this happens all the time. I can assure you, that this is not how shareholders or customers want you to spend your time.

nikau 2y ago
A lot of this comes down to budgets - those 10 people have a fixed salary so there is no visible cost.
- osigurdson 2y ago
  Those costs should be made visible as they are real. The price of each meeting should be included in the agenda.
  - wild_egg 2y ago
    Have you seen this done anywhere? I have to wonder if it would even have any impact
  - evilduck 2y ago
    If salaries were transparent and queryable this could even be a Slack or Teams plugin. But most org cultures would never dare expose salary imbalances like that.
    - shepherdjerred 2y ago
      There is this project: https://github.com/syncfast/clockwise https://github.com/syncfast/clockwise
bobmcnamara 2y ago
I work in embedded. When I told my boss I was leaving he asked what the other company was offering me - compiler licenses. Without enough each firmware build took 40-60 minutes. With enough, 10 minutes.
- djstein 2y ago
  hey! would love to hear your experience about this. we’re building a system that should help alleviate this pain when developing embedded systems. emails / cal link are within my person site on bio!
  - bobmcnamara 2y ago
    We were using a CPU core vendor's compiler with flexlm licensing(well, Edison Design Group frontend and proprietary backend). We kept using it for ages because it regularly beat GCC due to some issues in GCC with register allocation and instruction reordering that only microchip seems to have ever fixed. A traditional makefile like setup would only build one compilation unit per compiler invocation. Each compiler invocation requires a license checkout over TCP. This was badly impacted by Nagling and delayed ACK. The license server was not managed by engineering rather the IT department so we were unable to get them to enable TCP_NODELAY. Multiprocess scaling was challenging - you could give the compiler multiple compilation units, but sometimes doing so would effect the order of things in the object file, now you lose reproducible builds. These seemed to always be minor things that didn't significantly effect the executable, but rarely you'd crash the compiler and all its jobs would need restarted on the next rebuild. For those of us batching our compiler invocations for local development builds, the last straw came when an ops team unfamiliar with the tools was put in charge of license management. They started kicking out license checkouts beyond a few seconds in the name of fairness. Build times increased further, but license checkouts per second went up so they thought they were helping. Eventually I realized it wasn't the 1970s anymore and since I no longer smoke I was bored out of my skull just waiting for timesharing computer to compute again. Several teams did move to GCC when it got bad enough - hand tuning loops and such when needed. Probably shouldn't've had so much code in headers - APIs had a lot of dependencies and when I needed to change CompanyName.h, I was in for a few 90%+ rebuilds. It was a combination of: not my problem, nobody's problem, I got mine, codebase is already like that, death by a thousand cuts, we've never better so how can you say this is bad, network latency.
albrewer 2y ago
> Imagine, holding a 2 hour, 10 person meeting to decide if an additional one time $1000 cloud expenditure is warranted I don't have to imagine; I've had it happen within the last month. IT was complaining about dev's storage usage. It would have been cheaper for them to buy 10x 20tb hard drives than pay for the meeting that was called about it. Luckily, when that was pointed that out in the meeting, the dept manager agreed and ended the meeting shortly after.

nikau 2y ago

A lot of this comes down to budgets - those 10 people have a fixed salary so there is no visible cost.

osigurdson 2y ago
Those costs should be made visible as they are real. The price of each meeting should be included in the agenda.
- wild_egg 2y ago
  Have you seen this done anywhere? I have to wonder if it would even have any impact
- evilduck 2y ago
  If salaries were transparent and queryable this could even be a Slack or Teams plugin. But most org cultures would never dare expose salary imbalances like that.
  - shepherdjerred 2y ago
    There is this project: https://github.com/syncfast/clockwise https://github.com/syncfast/clockwise

bobmcnamara 2y ago

I work in embedded. When I told my boss I was leaving he asked what the other company was offering me - compiler licenses. Without enough each firmware build took 40-60 minutes. With enough, 10 minutes.

djstein 2y ago
hey! would love to hear your experience about this. we’re building a system that should help alleviate this pain when developing embedded systems. emails / cal link are within my person site on bio!
- bobmcnamara 2y ago
  We were using a CPU core vendor's compiler with flexlm licensing(well, Edison Design Group frontend and proprietary backend). We kept using it for ages because it regularly beat GCC due to some issues in GCC with register allocation and instruction reordering that only microchip seems to have ever fixed. A traditional makefile like setup would only build one compilation unit per compiler invocation. Each compiler invocation requires a license checkout over TCP. This was badly impacted by Nagling and delayed ACK. The license server was not managed by engineering rather the IT department so we were unable to get them to enable TCP_NODELAY. Multiprocess scaling was challenging - you could give the compiler multiple compilation units, but sometimes doing so would effect the order of things in the object file, now you lose reproducible builds. These seemed to always be minor things that didn't significantly effect the executable, but rarely you'd crash the compiler and all its jobs would need restarted on the next rebuild. For those of us batching our compiler invocations for local development builds, the last straw came when an ops team unfamiliar with the tools was put in charge of license management. They started kicking out license checkouts beyond a few seconds in the name of fairness. Build times increased further, but license checkouts per second went up so they thought they were helping. Eventually I realized it wasn't the 1970s anymore and since I no longer smoke I was bored out of my skull just waiting for timesharing computer to compute again. Several teams did move to GCC when it got bad enough - hand tuning loops and such when needed. Probably shouldn't've had so much code in headers - APIs had a lot of dependencies and when I needed to change CompanyName.h, I was in for a few 90%+ rebuilds. It was a combination of: not my problem, nobody's problem, I got mine, codebase is already like that, death by a thousand cuts, we've never better so how can you say this is bad, network latency.

albrewer 2y ago

> Imagine, holding a 2 hour, 10 person meeting to decide if an additional one time $1000 cloud expenditure is warranted I don't have to imagine; I've had it happen within the last month. IT was complaining about dev's storage usage. It would have been cheaper for them to buy 10x 20tb hard drives than pay for the meeting that was called about it. Luckily, when that was pointed that out in the meeting, the dept manager agreed and ended the meeting shortly after.