I really love Copilot. I had a trial, let it expire because I thought I wouldn't really need it, and then ended up paying for it. It's apparently got even better. For me, at least, it gets most things very right and takes a lot of mundanity out of day to day development!
I work in Finance, if I type a certain client name out in public, I can be fired for it. Can copilot work without the internet and within only a corporate network ?
You might be interested in IntelliCode from Visual Studio. It's an AI-guided autocompletion tool, like Copilot, although dumber and less powerful. It can run in local mode [0], looking at your existing codebase (opened solution) to feed future suggestions.
> [...] The GitHub Copilot extension sends your comments and code to the GitHub Copilot service, and it relies on context, as described in Privacy below - i.e., file content both in the file you are editing, as well as neighboring or related files within a project. It may also collect the URLs of repositories or file paths to identify relevant context. The comments and code along with context are then used by OpenAI Codex to synthesize and suggest individual lines and whole functions.
No, you can already use offline alternatives like tabnine but it's not as good. But I guess better opensource models and tools will be available eventually.
I don't think there's been any better value for me than Gary Bernhardt's Destroy All Software. I randomly stumbled upon it way back in 2014 when I had just learned my first programming language and was dabbling in Ruby, watched everything, and it made me much better at my job. It was $29/m at the time.
Apart from that, I think maybe one or two books every year. Most of them are pretty poor, but the value of that odd book that totally changes how you think about certain things is pretty high. A lot of technical books also have _really_ good, practical advice that can be applied to day-to-day work if you want to read them. It's pretty valuable to know the technologies you're working with in some depth.
Write a lot! Writing will almost always force you to think clearly, notice gaps, and just generally get a better understanding of what you are trying to do.
Write down everything, the problem, all that you are thinking, approaches, everything.
Writing is huge help for me. One issue I have (a perfectionist streak?) is that I tend to treat written things as a wiki-style knowledge garden system. This is a huge time sink. Whenever I want to add some detail I have to re-read whole structure and figure out where I want it, and I have desire to correct or restructure dozen things I wrote before. The pay-off I get from such system is not great because it's just mirroring the information I already know.
I now use a system that's more like diary. Some notes are relevant for single day, others for a week. Anything older than that, I treat mostly as read-only. I'm ok with repeating myself over and over. It sets the context for thinking and decisions, and allows me to modify and correct assumptions over time. At the moment I use Trilium Notes for this, but still exploring other options. I would love something that includes diagrams and mind maps.
Unexpected benefit is that when I work while distracted and unmotivated, writing down each step and outcome allows me to stay on track and slowly make progress. Context switching becomes easier.
It's Write-Only notes - you can only see the previous line at any one time, and editing is intentionally difficult. You write, then at the end you see what you wrote. I've found it really useful (as someone who has the same tendencies you describe.)
Assuming you have some experience building simple single-node systems:
- Read Designing Data Intensive Applications. As others have said, it's a gem of a book, very readable, and it covers a lot of ground. It should answer both of your questions. Take the time to read it, take notes, and you should be well set. If you need to dive deeper into specific topics, each chapter links to several resources.
- Read some classic papers (Dynamo, Spanner, GFS). Some of these are readable while some are not-so-readable, but it'll be useful to get a sense of what problems they solve and where they fit in. You may not understand all of the terminology but that's fine.
That should give you a strong foundation that you can build upon. Beyond that, just build some systems, experiment with the ideas that you're learning. You cannot replace that experience with any amount of reading, so build something, make mistakes, struggle with implementation, and you'll reinforce what you've learned.
Backend is vast, and this helps you build a general sense of the topic. When you find a topic that you're really interested in (say stream processing, storage systems, or anything else), you can dive into that specific topic with some extra resources.
> I understand Postgres the best, and would love to know why these and others exist, where do they fit in, why are they better over PSQL and what for, and if they are cloud only what's their alternatives....It seems all of them just store data, which PSQL does too, so what's the difference?
A lot of that depends on the way you're building a system, the amount of data you're going to store, query patterns, etc. In most cases, there are tradeoffs that you'll have to understand and account for.
For example, a lot of column oriented databases are better suited for analytics workloads. One of the reasons is for that is their storage format (as the name says, columns rather than rows). Some of the systems you mentioned are built for search; some are built from the ground up to allow easier horizontal scaling, etc.
Looks pretty interesting. I took a computer architecture class in Jan-Feb this year, and it was one of my favorite things in a long time. I've written software for ~6 years but I didn't really know much about how CPUs work, what an instruction is, what registers are, etc. so I learned a lot.
I thought a lot of these details could be boring or hard to grasp, but it was the opposite—to me, things like how logic gates worked, how we remember values between computer cycles were all very fascinating, especially compared to the kind of work I've done for a long time.
I've learned a bit more about operating systems and databases since then, and I think knowing a bit of computer architecture helped me understand several topics in much better depth. So even if knowing these things doesn't have a very direct ROI in terms of getting a job, I think it's worth spending the time to learn at least the basics.
Yeah, although I think understanding how computers work at a basic level (the components of a CPU, what instructions are, caches, etc.) has a pretty good ROI because it makes it easy to understand some concepts at a higher level (concurrency for example), understand why some things work a certain way, think about some common performance optimisations, tradeoffs, etc.
I think that's true of most things—you don't need to (and likely cannot) know everything in real depth, but having some knowledge tells you where to look, what to look for, etc.
I've found it hard to be consistent with it, but basically just waking up really early. I get ~4 hours of calm, focused time to read or do whatever I want.
Jacob Sorber is great, thank you! It seems he doesn't have so many views because his videos are mostly just 4-5 minutes, "surely not long enough to do anything serious"...but they're so brilliantly done, marvels of clarity and concision.
Agreed. I'm reading it just now and it is really high quality. Just the chapter on transactions is probably the best explanation of a single topic that I've read in any technical book. It's really good for such a complex topic—thorough while still being very readable!
