Yes I did feel the same, and it boiled down to accepting I had to try something new that I thought I didn’t want or be happy with what I already had . You have several options I guess.
- it’s very likely you haven’t mastered all layers of the stack - you maybe have mastered the parts you’ve come across though. Would you include Linux kernel development, program proofs, HPC , math-oriented software, compilers, firmwares, fpgas, database internals ( I mean, writing a full database engine ), big iron infrastructure , actual research etc in the list of things you’ve mastered? That’s what I did for many years ( not necessarily these topics ) - keep exploring , the field is massive. In my experience, the more you look around the more you realize that you haven’t seen it all, and even less mastered it.
- now, in my case, after doing just that ( trying new technical things) I realized I was getting increasingly interested in the overall technical strategy and interplay with people more so than the purely technical side of things. I had vowed I would never get into the higher spheres … but I am now essentially a principal engineer ( or whatever you call that but basically I lead some technical stuff ) for a very large org. This is not management , and I really like it. I keep learning about people and business, about how changing something big is hard and human , and balancing technical problems with human ones . It’s fascinating, and above all grounded in technical knowledge so I don’t feel like I’ve thrown away a significant chunk of my career.
In particular, if you feel that you’re not being listened to but would like to, maybe you’d be interested in that kind of job. If you’re saying you’re not always succeeding at persuading people , it probably also means there’s growth for you here, and satisfaction down the line.
- actually get into management , which like most topics is actually interesting once you get into it. It’s just different. I thought I didn’t like it - I actually do and that was a colossal surprise to me.
Whether it’s technical leadership or management, these skills can be learned, and they make the bits that you don’t like much more palatable, and the bits that are ok very enjoyable. I was lucky enough to meet very good people who taught me properly. I think this is very important. I can cook at home, but if I get proper training my food will be better and I will enjoy the process a lot more ( try chopping vegetables with no training - you’re slow as hell and it ruins everything)
- do something unrelated ( cooking etc ). To be honest, at some point I did my job but the more fulfilling exploration part of my life was at home and revolved around food. I did consider changing career completely but decided it was too risky.
To a large extent, there is limited value to your extensive knowledge if you remain at the bottom because it will always have limited impact. You seem to want the power and influence ( for good reasons !), but don’t seem to want to learn the skills that are required . ( at least management, you seem interested in technical leadership). I guess you have to choose. It’s very hard, but liberating.
You mentioned family - I also made sure I was in a good place at home when I switched. I found it hard but support from my wife helped tremendously.
Thanks for the insights. I have been in technical leadership positions in the past, but disliked the management part. I think that the other dilemma is that I don't like big companies, as I've only had negative experiences and I get frustrated because even the most tiny thing can take forever to be done.
> it’s very likely you haven’t mastered all layers of the stack - you maybe have mastered the parts you’ve come across though.
I was meaning that in the context of web dev. There are certainly other areas I don't know much yet.
> Would you include Linux kernel development, program proofs, HPC , math-oriented software, compilers, firmwares, fpgas, database internals ( I mean, writing a full database engine ), big iron infrastructure , actual research etc in the list of things you’ve mastered?
Definitely not (except partially a database engine), but I'd definitely like to move down the stack. I like systems programming, low level stuff and optimization problems, so that's maybe the main area that I should explore (and also one of the reasons I like game dev). Translating that into an actual job might be harder thought.
Maybe I’m misunderstanding something - if I store my data elsewhere , am I not supposed to encrypt it anyway, with my keys ? If the crypto is strong enough then surely cloud providers can’t do anything with it ?
> Maybe I’m misunderstanding something - if I store my data elsewhere , am I not supposed to encrypt it anyway
"Cloud" is not only for storage; it's also for compute. Doing compute directly on encrypted data (homomorphic encryption) is very slow and very complicated, so when using a cloud, the data is usually either unencrypted, or encrypted but the key is elsewhere in the same cloud.
I get that FHE is not realistic today, but can’t I use ( if it’s really critical) a combination of confidential vms and an external hsm ? I understand I’ll be limited to traditional workloads , and not managed services though.
I asked the wrong question, what I really meant was ‘if I run in a less trusted environment, am I not supposed to use all possible crypto mechanisms available to make that environment more trustworthy , so that I can’t be deceived by my cloud operator sending my data to the us government’
That's just not possible. It's why detractors never got on board with the Cloud. Until FHE is feasible, the decryption keys and plaintext have to exists in RAM eventually at some point in order even if only took be re-encrypted, if any complex work is to be done on it. Because eg, Amazon, has access to your hardware, there's simply no way to prevent them from reading your secrets out of your VM that's using their RAM.
Absolutely do what you can, but understand that it's futile to defend against your own cloud provider.
Ok I thought that was the whole point of things like Intel TDX , AMD SEV and various enclave mechanisms which provide full ram encryption and attestation ?
The only issue left would be managed services though, which then I wouldn’t use, but I’d be able to run my own postgre safely on infra I’m renting.
Supposedly, yes, but in a world that was caught flat footed with RowHammer, Spectre, and Meltdown; if I wouldn't trust those with a lot of other people's lives within a shared Cloud environment.
Intel's SGX has been broken a number of times and that should be harder to break than TDX. Like I said in my original comment though, do all the things. But if you find yourself relying on TDX to protect live(s), please pay a computer security professional to audit your security and do a threat assessment.
I’ll do all the things if ever needed, but I get that if a cloud act request happens , your cloud provider will be able to get your stuff.
I’m specialized enough in another field to know that I’m not a security person in spite of my interest in it ( I used to enjoy reverse engineering back in the days ) - I wouldn’t make that kind of decision without consulting a professional first.
I do mostly agree with you that Steam is better as a storefront than all other ones out there, but in my opinion the Battle.net launcher is still my favorite game launcher edging out Steam because of how snappy it is.
Steam just sometimes feels really slow when launching for the first time or when switching tabs/pages (I do also have it just sometimes be just a black windows, but I haven't figured out the cause yet but it is the only window that does it, so...). In comparison B.net just feels decently snappy.
They are both effectively using CEF for their launcher, but since Steam starts so slow for me I always keep it in the background and its WebHelper taking up 414MB (rn, but its always in that ballpark) is not helping its case.
People favored Google as much as possible in the '00s and then they turned evil.
For games, I favor Good Old Games rather than Steam as much as possible and go out of my way to wait for releases on their platform. Whatever becomes of them, at least I'll have my downloaded DRM-free version of my purchases.
I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things.
My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home.
Now, if you’re able to indicate what’s important and not important, what’s interesting and what isn’t , and why you like it , I’ll be delighted to watch your talk.
I think it’s very difficult to be interested in something new if the presenter doesn’t seem to care about it. This is different from something written , where I expect something dry anyway.
The git documentation is one of the nastiest docs ever just like the whole git ui. It’s technically entirely correct, but won’t help you understand how it works in any way.
It’s exactly like folks in 1995 telling you to rtfm when you’re trying to install Linux from a floppy disk. It’s doable, but annoying, and it’s not that easy.
That's really unexpected.
To me, git documentation was one of the best cleanest official docs I've ever read.
Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a good head start) if you decide to develop your own jujutsu or kurutu or whutuvur.
The book says that ‘ To really understand the way Git does branching, we need to take a step back and examine how Git stores its data’ then it starts talking about trees and blobs.
At that point you’ve lost almost everyone. If you have a strong interest in vcs implementation then fine, otherwise it’s typically the kind of details you don’t want to hear about. Most people won’t read an entire book just to use a vcs, when what they actually want to hear is ‘this is a commit graph with pointers’.
I agree with you : the information is there. However I don’t think you can in good faith tell most people to rtfm this, and that was my point.
To be honest, if you’re using a tool that stores things as trees and blobs and almost every part of its functionality is influenced by that fact, then you just need to understand trees and blobs. This is like trying to teach someone how to interact with the file system and they are like “whoa whoa whoa, directories? Files? I don’t have time to understand this, I just want to organize my documents.” Actually I take that back, it isn’t /like/ that, it is /exactly/ that.
I see your point but … trees and blobs are an implementation detail that I shouldn’t need to know. This is different from files and directories ( at least directories ) in your example. What I want to know is that I have a graph and am moving references around - I don’t need to know how it’s stored.
The git mental model is more complex than cvs, but strangely enough the docs almost invariably refer to the internal implementation details which shouldn’t be needed to work with it.
I remember when git appeared - the internet was full of guides called ‘git finally explained ‘ , and they all started by explaining the plumbing and the implementation. I think this has stuck, and does not make things easy to understand.
Please note I say all this having been using git for close to 20 years, being familiar with the git codebase, and understanding it very well.
I just think the documentation and ui work very hard towards making it difficult to understand .
> I don’t think you can in good faith tell most people to rtfm this
I can, and I do.
The explanation in that book creates a strong coherent and simple mental model of git branching. I honestly can't think of a better explanation. Shorter? Maybe. But "graph with pointers" wouldn't explain it.
So based on my experience teaching git ( I remember a cvs to git migration …) , reality tells me people find git difficult.
Now, once you teach them it’s a commit graph with names, some of them floating, some people get it.
The thing is, not everyone is comfortable with a commit graph, and most people are not - just like people get lists and arrays but graphs are different.
So I agree with you on principle ( it shouldn’t be difficult), but most people don’t have a graph as a mental model of anything, and I think that’s the biggest obstacle.
I don't use these tools that much ( I tried and rejected Cursor a while ago, and decided not to use it ) but having played with GPT5 Codex ( as a paying customer) yesterday in regular VSCode , and having had Composer1 do the exact same things just now, it's night and day.
Composer did everything better, didn't stumble where Codex failed, and most importantly, the speed makes a huge difference. It's extremely comfortable to use, congrats.
Edit: I will therefore reconsider my previous rejection
reply