| |
| ▲ | jacquesm 6 hours ago | parent | next [-] | | Next week: hey, I'm out of a job, what happened? | | |
| ▲ | pjmlp 6 hours ago | parent | next [-] | | This is what I don't get with the kind of posts you are replying to. I have experienced directly what the evolution of cloud based software, and now AI based tooling, has done to team sizes on delivery projects. Cannot understand how they don't get how all the performance improvements directly correlates to smaller team sizes, in shareholders driven economy. So far I have been lucky, and just hope to have enough savings when time comes, as finding jobs after 50s wasn't already easy without having to add AI on top. | | |
| ▲ | xyzzy123 3 hours ago | parent | next [-] | | Most of the world does NOT optimise for efficiency, particularly at the big end. Really big hyperscale companies (and some startups) are unusual because they at least sort of try, most of the world is not even trying. The org structure is optimised to reduce or even minimise individual agency, explicitly at the cost of efficiency. Teams have fiefdoms, private repos that the rest of the org can't see. You are not granted permission to see what permissions you have. Byzantine department structures. Shipping "hello world" to production takes 3-6 months and nobody can imagine it working any other way. There's actually no central directory of teams or processes. To get anything meaningful done, you need the co-operation of maybe 8 teams but there's no consistent way to engage them all. You have to negotiate with them all in different ways, they're like little warlords, sitting and guarding access to some vital resource you need. They have established a ticket-based interface with a 7 day SLA on top of a perfectly good vending API that could do what you need in seconds. Sometimes a blocking team has a 3 month backlog so your project will just have to wait. Everything is always in the process of being restructured, so no end to end 6 month process happens the same way every time. These organisations could use AI to run the end to end process in minutes. Heck, they could just put APIs on top of what they already have. But the way they WANT to use it is to keep doing what they're doing but with EVEN MORE form filling and paperwork. You would think they would get outcompeted, but no. The "IT organisation" sits like a brain slug on top of an enterprise with substantial regulatory, capital and execution moats. Big cuts of course do happen in these places, but it's often for optics (we need to signal that we care about efficiency, and AI is a great excuse). But you can't protect yourself by being efficient and good at your job, because the cuts were not about output. | |
| ▲ | garciasn 6 hours ago | parent | prev | next [-] | | Because I don't live in a world where my team needs to grow for me to feel more successful? My teams have been small and tight-knit at every place I've been an Eng leader. I left a job with 13 engineers and they're at >90 now, apparently doing less; but, that's just what I hear second-hand. I want to do MORE with the same amount of folks. | | |
| ▲ | soniclettuce 2 hours ago | parent | next [-] | | Was it a conscious or unconscious decision to reply to a chain with an argument of "headcount is obviously reducing" with "I don't need headcount to grow to be happy" without addressing the gap between those two at all? | | |
| ▲ | garciasn an hour ago | parent [-] | | I think you may be conflating two different arguments. I'm not disputing productivity improvements can lead to smaller teams, particularly in a shareholder-driven org; that's a separate conversation, IMO. The fact I work at an employee-owned organization, currently, I suppose I'm simultaneously a worker and an influential shareholder. I was trying to say, running counter to what is frequently mentioned on HN about FAANG Eng Leaders, that I don't equate engineering success with growing headcount. I've always preferred building small, highly effective teams that can accomplish more without needing to grow, just for the sake of growing headcount. My want to do more with the same number of people isn't an argument that headcount won't shrink. It's an argument that growing headcount was never my measure of success in the first place. No that you asked, but, my measures of success are: are my engineers happy (being that many of them have worked with me at least one company before, and one at 4, I feel they are); are we playing with the latest technologies; and are we learning new things every day? |
| |
| ▲ | ben_w 5 hours ago | parent | prev | next [-] | | > I want to do MORE with the same amount of folks. So do I, but I've been in two companies that had to let me go because the investors said they didn't want my role to exist any more. Plus two other roles where the company straight up ran out of money. It's not always up to us. | |
| ▲ | pjmlp 4 hours ago | parent | prev | next [-] | | I unfortunately have been in enough situations where team sizes get to shrink, unless there is some escalation going on. First it was offshoring, then managed cloud environments and servless, followed by ready made SaaS products, low code/no code iPaaS cloud products, and now agentic runtimes. The ones doing content translations, asset management were the first, followed by classical infrastructure people, then most backend roles, and so it goes. | | |
| ▲ | solyin 4 hours ago | parent [-] | | Not everyone makes the transition. In the rise of AWS, someone I know's last task at this one company, a company they'd poured their heart and soul into; it was to move everything off the on-prem servers that he'd procured and the company had been running in for years. He moved it all onto AWS, got rid of that hardware, and then he was out of a job. |
| |
| ▲ | jacquesm 5 hours ago | parent | prev [-] | | HR meeting in room #3, please bring your coat with you. |
| |
| ▲ | jacquesm 6 hours ago | parent | prev | next [-] | | I think it is because programmers are not that good at economy or running a business. Their bosses are though and they don't see a productivity tool, but a way to reduce their costs. | |
| ▲ | DANmode 5 hours ago | parent | prev [-] | | What about their comment says they don’t understand that? | | |
| ▲ | pjmlp 4 hours ago | parent [-] | | The whole positive content on the productivity outcomes. | | |
|
| |
| ▲ | tomcam 6 hours ago | parent | prev [-] | | I think that's this week |
| |
| ▲ | zamadatix 4 hours ago | parent | prev | next [-] | | Speaking of code golf, I had it optimize Diskitude into a <8 kb (still uncompressed) executable, add some features, and improve scanning performance all while increasing size. An LLM will gladly make extremely optimized software, you just have to ask for it. | |
| ▲ | derwiki 6 hours ago | parent | prev | next [-] | | > The week after that: everything is written in ASM. Also “1 month ago,” but s/ASM/Rust | |
| ▲ | Imustaskforhelp 6 hours ago | parent | prev | next [-] | | > The week after that: everything is written in ASM. This is an genuinely good minimalist good editor that is created in mostly assembly that was created with the help of AI[0] I maintain a fork of it which basically adds scratchpad ability to it and is something that I use daily myself for what it's worth[1] My fork was created with the help of GLM 5.3 (an open-weights model) The future is already here in some sense. I could in theory add more features but I intentionally add not more features because asm is still slightly difficult for it to write but in some sense the tradeoff has been/could be worth it. It was more of an experiment really and I am really impressed by it. in many ways, forcing AI to write asm does make you now think intentionally of features and ironically prevents feature creep and makes you think of stability of the product (atleast right now for me anyways) [0]: https://rhun.app [1]: https://github.com/serJaimeLannister/rhunpad | |
| ▲ | misiti3780 6 hours ago | parent | prev [-] | | i wish this was my experience, it's basically the opposite. im shipping a little faster -- but spending endless amounts of time reviewing LLM-generated code that usually isnt production ready. |
|