Basic does not mean "no software" it means "no cellular modem" and "no 15 inch tablet" and "no subscription based features"
There is functionally no difference between the powertrain of an electric road car and a brushless drill. How much software is there in your brushless drill? More than zero, far less than an electric road car.
That isn't realistic though, there will never be enough nannies for every family with children to have one.
If you wanted to pull a purely financial lever, you'd have to give couples enough money to offset one partner's income plus a lifetime of lost income due to the years spent outside of the job market.
IMO this would be perfectly fair and reasonable, considering they are raising a future lifelong taxpayer, but that kind of long term thinking is challenging.
That basically sounds like retirement. If you choose to stop working because of kids, you could be entitled to receive social security just like in old age.
This perfectly illustrates this broken mental model that leads to endless frustration.
Unless you put the car in reverse, you are still making forward progress. If someone merges in front of you at 30mph then you traveled hundreds of feet towards your destination in the time it took them to do that. Chill out.
Seconding campfire. Straightforward, easy to host, easy to backup, no monetization strategy. Most self-hosted alternatives have complicated deployments to enable scaling to >1,000s of users which I will never, ever need.
The level of trust didn't change at all, Joann must have read every single receipt as she filled out the forms. A fraudulent or out-of-policy expense would've been noticed either way.
High-trust doesn't mean absolute trust. Hand me a pile of receipts and I'll figure it out (probably with leeway in your favor) is much higher trust than uploading receipt, categorizing, adding explanations for exceptions, etc. One feels reasonable and still dignified. The other feels adversarial and paternalistic.
Joanne probably had to field some "sorry, this can't be expensed" situations, and/or those were reduced because people knew another human was doing the work and they'd get called out, trying to game/abuse the system was less or just naturally discouraged. That was high trust, by both the employee and by Joanne.
With the employees needing to use Concur directly, there's a tendency, since there's a diversity in how each employee will handle the specifics, to try to "save money" by denying reimbursements for any random violation, making sure all i's were dotted and t's crossed. The automated system itself encourages this because it's so low effort to deny and send the expense form back, potentially wearing down the employe that they just give up. Joanne could avoid all that at scale because there was little/no diversity in how expenses were handled. If an i needed to be dotted, she could handle it, and she knew all the i's that needed to be dotted across all expense reports.
I currently have someone to handle my expense reports who sits in front of Concur for me! And that person routinely asks me for specific detail without me having to mess with Concur at all, things like "who was at this dinner you gave me a receipt for" or "I can't find the receipt for this company card charge".
I work at an organization that uses concur. My team work at the other end of the process. They take Concur outputs and pay the claimants back. We find that somehow makes us the support department, adding users, training them, and worse still teaching them how to get around rejections. It is a bit less work for us than the paper forms I started my career with. It does rather push the overhead of claiming the expense onto the claimers though, many of which tend to be those whose time is most expensive. I'm not sure it works out.
This, the person nitpicking the Concur entries might as well have done Joanne's job and achieve two things at once. Compliance to concur and the regulatory compliance built into the concur process and not wasting everyone's time doing concur
> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.
Do most engineers find this to be true? For me the balance switched within a few years of being a senior (nearly a decade ago). Writing code is easy, negotiating over what code to write takes time.
I have found it to really depend on the company. Large companies, there is a ton of time spent on architecture reviews, paperwork, design, hitting new library updates, etc. That work is on seniors, then mid levels do a lot of the actual coding (at least in my experience).
But I have worked in some areas that its not like that. What we are building is decided pretty quick, but the implementation takes a month of two.
The constant back and forth between architecture and product and project management roles is the new norm for more senior/staff engineers it feels like. rarly do i get an opportunity to work on code during regular hours.
my days are spent in meetings discussion how to implement things or why do it certain ways - when most of that time spend asking inevitably turns into "when can this be ready?"....well if you didnt have me stuck discussing it for the last 6 months it would've been ready yesterday like you wanted.
I'm with you and I'm a solo dev right now. Reading, understanding, and trying to decide what is the right code and how that code fits is the most time consuming.
Really depends on the company. For me it isn't true, but it used to be when i worked at a bank with terrible management. Nowadays i'm in a tooling team (for Network and security teams), where my "clients" are other devs from the same company. Of course we still have negotiation, but i'd say 60-80% of my time is spend coding, and that's with me being basically a "senior".
And by the way, one thing is missing from the OP graph: i now spend maybe 50% less time writing my own code, and 100% more time fixing my juniors PRs and fixing production issues after my reviews miss issues...
That's my experience too. And my employer has generally internalized it into their process: instead of negotiating over what code to write, write it all the ways, A/B test them, and negotiate over which code to launch once you have more data about how different approaches might affect user behavior.
Interestingly though, the experimentation process itself seems very under-optimized, and so it is frequently the bottleneck.
I find that I spend less time reading, writing, and debugging code. That much is true. But it has been replaced with context switch recovery time. Its like having a coworker who nags you every few minutes. I see no apparent increase in output. The bottleneck just moved the goalposts around.
Funnily enough at least in my personal anecdotic case it works about like that. I do just remember when my meetings will be (or look up where the meeting was decided on), do try to remember what I had planned (sometimes I forget, but almost always for the better), and written notes are rare enough that pen and paper are sufficient. And also don't have a driver license. I don't think my case is exactly rare, even among softdev croud.
And I am pretty sure every single one of those "billions of people" have had the experience of returning back from the grocery store, only to realize they were actually out of eggs.
reply