Twitter used to have a Firehose API, too. Over time they closed it, and made it only available to large users like Google Search with real-time indexing needs.
Twitter had a really outstanding search and streaming API, but after Musk bought it they put it behind a $60k/year paywall. You can see a corresponding and abrupt falloff in academic network research papers, with newer ones that revolve around Twitter largely limited to cannibalizing old datasets.
With luck bsky keeps growing and researchers invest effort in studying a more open-by-design platform.
OK, I'll bite. I think if you're a technical team lead in a large organization, it is rather your job to point out what's working and what's not working from a technical perspective. If managers could figure this out, they most likely would not end up being people managers after all (insert if those kids could read meme.jpg). Sadly, nowadays even the most large tech companies have enough red tape and bullshit going on (OKRs, alignments, escalations, Q4 plannings, weekly 1:1s with all reports etc) to keep people managers full-time occupied. Most people managers nowadays neither have the chops to understand the work that's taking place on the ground, nor have the time to track it.
So it falls on a tech lead to point out who are the sailors in the ship that are not rowing (or worse paddling backwards). I'm not saying "go build a git commit counter dashboard" but if you're working with dozens of people and it appears someone isn't delivering a lot of work lately, it helps you double check your assumption. (Again, not saying commits are a good metric.)
This blog post is definitely relatable to most of us because we join teams that are somewhat dysfunctional, and if you have the influence capital and the chops to turn that team into a place where hiring is done properly, people have motivated and the right amount of work and the room to grow, I think you can turn the ship around. Or maybe I'm too naïve and have a lot more to learn.
That just means as a tech-lead you end up not only putting blame on the (broken) tech but also blame the people right with it?
I don't think that is a smart thing to do within office politics.
I do agree that you can elevate people with potential, to build something of value with them, but I would stay away of trying to get people fired or replaced.
If your job is not to manage people then their performance shouldn’t really matter to you. If the company wants you to care about that they should give you actual management duties (and the pay which comes with it).
It’s obviously cheaper to have technical leads be a kind of pseudo managers where you get them to do most of the middle management, their own work and the reporting. This way you can save a lot of money by keeping the financial parts away from the technical leads, which also means you don’t actually have to listen to what they say about performance. Because one of the major truths about management is that a mediocre performer is usually a good keep since they are cheap labour and less likely to leave. Sure you can do stuff like cutting the poorest 10% and I think this is popular in the US, but that usually doesn’t invoke the best productivity because it hurts morale. This way you can also semi-easily replace your pseudo-middle managers because the hardest part of management isn’t the day to day stuff, it’s balancing the spreadsheets and making your own successes look good.
From a top decision maker perspective the separation also makes sense in terms of not having too many responsibilities tied to a management area which is notoriously hard to get talent for. If your tech managers are too technical, or if your technical leads are too invested in management it’s much more expensive when one of them leaves.
The unfortunate side effect is that it often burns technical leads out. Makes them unhappy when they are passed over for promotions or don’t feel they get credit for the work they do. There is no easy solution though because managers tend to change jobs much more often than most other “more expensive to replace” positions. I suspect a lot of technical leads might also find the corporate politicking between middle management and managers or managers very stressful.
I don’t know if you’ve worked in a large corporate environment but usually your success depends on others. If you’re a a tech lead, you rely on other individuals to deliver. If the whole project fails, nobody gets their promotions or bonuses anyway. So it’s rather a collective effort to get the teams in a well executing state.
I don't really disagree with anything here, except that I think "not my job, not my problem" is at best a sign of unhealthy dysfunction, and not something to aspire to. Well, for most people; probably certain annoying activist meddlers could settle down and focus more on their own areas. And I suppose it can be a rational self-protective mechanism when you're stuck in a really dysfunctional place, as doing too much "not in the exact letter of my job contract" types of work can quickly lead to burnout, but it'd still be better to look for something new... As the thread's current top comment mentions, when you disincentivize things like "Helping a colleague" or "Digging into what looks like a security vulnerability", that's just incredibly corrosive and makes dysfunction even worse. It doesn't matter whether you disincentive such things with bad management dashboards or with encouraging an attitude of "not my official job duties, don't care".
It's not quite a matter of "professionalism", and I very much don't want programming to turn into something that requires a professional engineer stamp like other engineering disciplines, but professionalism might be the best proxy term. I want to work with people who do good work. Even excepting the cases where someone else's bad performance or work actually can directly impact me or the rest of the team's work or reputation, I'd rather work at a place that discourages bad performance. If management appears blind to a particular instance, it may well be worth saying something to try and correct it, even if performance of the system is ultimately their responsibility. Each place is different, maybe saying something will actually improve things, or maybe it just ends up being another one of the hundreds of cuts that eventually make you conclude the place sucks with management not interested in improving it or themselves, and you go elsewhere.
There's a similar notion with introducing better technical practices like version control. Another comment mentioned struggling to get git adoption, but there are plenty of other stories of the opposite, where you do get a team to adopt something without the threat of management forcing it on everyone. Those experiences are great, I'm glad to have had several of them.
For sure, if you're being asked to be "tech lead", you should at least be getting paid as much as any of the direct managers of the team. In the age of "parallel promotion tracks", there's enough truth to that convenient fiction that this shouldn't be too difficult to achieve. (There is the downside of dumb processes like having to perform "at level" for several months to prove you deserve a promotion. You're basically taking a pay cut for that time, so better argue for sufficient compensation increase/bonuses when that promo comes.. and justifiably ragequit if passed over.)
I just did a two-way total 12 hour Hawaii flight and watched 12 hours of Apple TV series in a fully immersive environment completely isolated using Vision Pro. As long as the airplane seats have AC charger, you're good to go. I also use the Dual Solo Knit Band mod to increase head comfort.
I've gone through this phase a while back where I had to choose an init process (PID 1) to run multiple-processes in a container. Here's my write up here. s6 is in there as well. https://ahmet.im/blog/minimal-init-process-for-containers/
Truly puzzling why Google is doing these things that do not scale. Their DNA historically has been doing things for billions of users, not 10 companies that might ever pay for this. Google is a technology company through and through, they have a great engineering talent, and they can keep shifting paradigm in many areas, especially in cloud. Yet, the short-term profit motive of the rot economy is taking another tech giant hostage.
One of the more interesting things was the MBAs don't run engineering, it was fascinating seeing how quickly the tide can go out on management quality, especially when you're growing 20% every year -- took maybe 4 years to form a new extremely agreeable layer over significantly worse quality than the one 2 layers above it. Kiss up, kick down.
You realise that the idea that developers who work at google are more intelligent than average is the product of the work of marketing graduates who work at google?
They invested in a dead end AI technology. They, like all the other players in the space, are trying madly to recoup their original investments. It turns out "chat bot" is not a viable product on any level whatsoever.
This seems pretty adjacent to their existing cloud business not requiring major new investments and is likely a requirement to do bigger deals with customers.
reply