51–60 of 242 posts
Is “apple silicon” the port job here? Isn’t this more correctly described as a port of their existing ARM64 target to macOS?
(Why did 3 other people interpret this comment as saying something about iOS?!)
Earlier quoted context omitted.
This exists in almost every company by design. Engineering teams wouldn't make any progress towards their mission if they are constantly dealing with outside interruptions, but at the same time there are things which should be qualified. Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What managemen…
The binary distinction between "cost centers" and "profit centers" has always seemed arbitrary to me (especially since, as an engineer, I've been in both without my work being substantially different). To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new fro…
"Cost center" can be transformed into something else given both an understanding that support can and should contribute to future sales, and an organization capable of putting that understanding to work.
I have seen a similar scenario in manufacturing where various setup, prep, quality tasks are seen as cost centers and minimized.
Doing this kind of thing has ripple costs. Always.
In a perfect world, we make software, or hardware, and it just works and people grok it.
In the one we live in, these are fantasies and we can choose to understand, recognize the value, or not and get the benefits or not.
The users, customers, move from role to role, and support often determines their willingness to use the product again. That is straight up powerful marketing by referral.
Support often is the first to understand a user, customer needs an option too, or add on, replacement, preventative maintenance. Done right, these leads into lean, consistent sales.
"Cost center" to me has always been a bit silly in this way. There is opportunity to add value throughout the chain of people, process, machines, systems that are all necessary to properly conceive, realize and deliver something to others.
One thing often missed along with failing to understand value is failing to ask to be compensated for it.
Doing things in a robust, high value for the dollar way is not the cheapest way, in terms of raw product price, and depending, size of margin.
But, we do get what we pay for too, and the lowest price often comes with externalities paid by both the enterprise and its customers too.
Sometimes I see this all framed as a luxury. That is just as much of an error, and does come with unnecessary costs and or poor alignment with actual value.
Earlier quoted context omitted.
The binary distinction between "cost centers" and "profit centers" has always seemed arbitrary to me (especially since, as an engineer, I've been in both without my work being substantially different). To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new fro…
x% of support requests are of questionable nature - to mention just a few categories: * people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training) * people unwilling to RTFM, google, youtube, etc. * people whining when a general purpose tool doesn’t fit their exact workflow to a tee
Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads.
Fact is, people do what they do and they have their reasons.
Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does.
Net happiness goes up too. True for the enterprise and users, people at large.
Earlier quoted context omitted.
x% of support requests are of questionable nature - to mention just a few categories: * people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training) * people unwilling to RTFM, google, youtube, etc. * people whining when a general purpose tool doesn’t fit their exact workflow to a tee
Those are all sales and service opportunities, BTW. Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads. Fact is, people do what they do and they have their reasons. Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just d…
Earlier quoted context omitted.
I was a back channel route to engineering at a company I worked for a while. A few of the engineers trusted me and a couple select customers / sales guys knew they could come to me to run a bug by me 'in theory' and if we had enough information I could unofficially run it by engineering without going through the song and dance of the typical support channels. I could get a quick ya or nay form them on some things and…
That sounds like a dream career -- any advice getting there when you've hacked on graveyard startups most your life?
I was a regular support drone as far as anyone knew.
I just had some connections that came about because I could be discrete and the engineers understood that I didn't bring them garbage too early (without enough information) or without good reason.
Earlier quoted context omitted.
Those are all sales and service opportunities, BTW. Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads. Fact is, people do what they do and they have their reasons. Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just d…
Not all sales and service opportunities have positive ROI
Is “apple silicon” the port job here? Isn’t this more correctly described as a port of their existing ARM64 target to macOS?
On iOS there are no web browsers other than Safari, per the app store rules. "Chrome" / "Firefox" / etc on iOS are just basically skins on top of Webkit. See 2.5.6 here - https://developer.apple.com/app-store/review/guidelines/ This is why you don't get any of the features / extensions / etc of Chrome or Firefox on iOS. Apple does this so that the mobile web can never replace apps that they have a monopoly on and get…
A bit tangential to the main topic of the post. They mention that they are working on another optimizing compiler Ion which will replace the cranelift compiler (which is still in nightly) as the new compiler for WebAssembly. They link the issue [1] tracking the change which also speaks about disabling cranelift. To my knowledge cranelift was made for the purpose of compiling WebAssembly in Firefox, so I am not sure i…
Cranelift - experimental, quick to port
Ion - production, slow to port
So Firefox on Apple Silicon got Cranelift first, but only in nightlies, and will soon get Ion in release builds - "become the new default" means it will replace the baseline compiler.
Earlier quoted context omitted.
This exists in almost every company by design. Engineering teams wouldn't make any progress towards their mission if they are constantly dealing with outside interruptions, but at the same time there are things which should be qualified. Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What managemen…
The biggest problem we have in software engineering is the lack of support staff. You don't think a civil engineer has to deal with minutiae of paperwork, but software engineers for some strange reason think it is ok to be inundated by clerical work all the time. The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc.
But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles.
When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).
Earlier quoted context omitted.
I was a back channel route to engineering at a company I worked for a while. A few of the engineers trusted me and a couple select customers / sales guys knew they could come to me to run a bug by me 'in theory' and if we had enough information I could unofficially run it by engineering without going through the song and dance of the typical support channels. I could get a quick ya or nay form them on some things and…
This exists in almost every company by design. Engineering teams wouldn't make any progress towards their mission if they are constantly dealing with outside interruptions, but at the same time there are things which should be qualified. Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What managemen…