Here are some things that are not that in software teams:
- managing your own calendar, meetings, memos
- organizing transport and stay on business trips
- tracking and later correctly filling in forms to expense the above
- and yes, tracking supply of office consumables
This and many, many more things have been dumped on everyone by short-sighted beancounting. Salaries of secretaries, graphics departments, finance people, etc. are legible, therefore cutting them is a "big efficiency win". But their work does not disappear - it gets spread out, distributed in tiny pieces to everyone else. Then you have specialists with 10x the salaries of aforementioned departments getting constantly distracted by work that is not the reason they were hired. And people are surprised that productivity doesn't track promised economic improvements, and that everything gets slow to build and expensive for "unknown reasons".
But that's what I'm saying. An office manager makes a team most effective. A team that has to track a bunch of office maintenance tasks makes them less effective. Their team priorities should be top.
> It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams
The modern day tech career required two things to exist. A PC in every persons home/pocket and a connection to the internet.
Both of those things came together in the mid/late 90's and gave birth the the modern day tech career. Since then the modern day tech career has changed very little if at all.
Anything before that was not even comparable. Mostly academic researchers and labs.
A bit earlier I think. Most businesses had PCs and LANs by the late 80s. I specialized in Netware and PC repair in the early 90s. Some graphics/desktop publishing on the side for fun.
The difference between the tech world in the late 80's (computers and software are common and important) and the rise of the smartphone/web eras is so massive as to be fundamentally different.
Yes, we had cars that existed in the 20's and 30s, but listening to those "oldheads" about what worked for them at that time if you were in the post-WW2 auto boom in the US wouldn't make sense. See also: aerospace pre/post jet propulsion.
My point was: Saying "this is what worked for me finding a job in the 80's/90's" isn't necessarily great advice, because it's not the 80's or 90's. If an oldhead says "this is what worked for me last year" sounds like he's giving useful advice.
Put succinctly: Oldhead advice is great when it's relevant, but oldheads need to understand that not all their war stories are useful. Feels like an extremely reasonable take, but strawman me some more if that's what gets you off.
I still remember the NetWare/PC guy coming to our house as a kid when I bricked one of my families early pc's. He said something like, "if you keep this up you will have my job some day."
We still didn't have the internet in our houses then, though.
Having decades of experience doesn’t necessarily blind one to the reality of less tenured folks. The reality is that there are externally observant and empathetic people at all ages who see and internalize the cause and effect patterns around them, and those that aren’t and don’t. The latter are for some reason more vocal than the former lately.
Having taken a minute to understand this, I agree with the chrome team - it's not a bug, but rather an unfortunate complexity of interacting with caching and a server. It's definitely a choice on their part to issue a request different than the one you asked for by partially satisfying it from cache and asking the server for the rest. But it's not an unseasonable optimization. At which point when their shorter range request fails, they have no way to message the 403 back to you and also give back the partial content. So they chose to pass back the partial content.
I think it's a bit more complicated. Returning partial content seems to be a valid response according to the spec. But the Content-Range and Content-Length headers shown in Chrome DevTools are clearly wrong, they should indicate what is actually returned. So I still think there's a small bug in how Chrome handles this, but solving this bug wouldn't help the author, as it's still the responsibility of OpenDAL to fix handling partial content on their side.
This seems like a better design than returning no data and a 403, and they wouldn't be the first people to run into it and have to properly handle a partial range response.
reply