_____s

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!

The Elephant In The Brain and A Philosophy of Software Design!

Are they on the Destroy All Software membership or somewhere else?

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.

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.

Depends on how you define advanced, but check out:

* Low Level JavaScript https://www.youtube.com/channel/UC56l7uZA209tlPTVOJiJ8Tw

* David Beazley: https://www.youtube.com/channel/UCbNpPBMvCHr-TeJkkezog7Q

* Jacob Sorber: https://www.youtube.com/channel/UCwd5VFu4KoJNjkWJZMFJGHQ

* Computer Science: https://www.youtube.com/channel/UCSX3MR0gnKDxyXAyljWzm0Q2

* Computerphile

I also like a bunch of streams (Jon Gjengset for example), and some with few but extremely thorough videos (like Leeren for vim).

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!

Most enterprise businesses win because of better sales and distribution, but your product ultimately has to support your sales. Salesforce had both (and other advantages). How does sales work in medium to large B2B? You'll get a RFP with a list of questions, you'll often get a list of features that company X wants. Naturally, as a company, you'd focus on building those features instead of optimising speed.

If the market values fast software, you'll see a lot more fast software. There _is_ a lot of unnecessarily slow software these days, so it _is_ starting to happen. Think Superhuman, Linear.app, etc. — an entire category of software based primarily on the idea of being fast, aimed at the power user. If these apps succeed, you'll see a lot more of them. If the market doesn't value fast software, most commercial software will be slow.

I'm not sure it's the cheap companies or developers driving this. Even companies that pay really well produce pretty slow software (Gmail, etc.). It's mostly the ecosystem in which software is developed.

As someone else said, businesses hire software engineers to solve business problems. Speed often isn't a priority. Fast software will make the experience perceivably better, but it's hard to get on a sales call and tell a potential customer that your application loads much faster when they are looking for feature X. And most companies buying software are looking at a checklist of features first and then maybe the experience.

You also need to put in the time to make software fast and then keep it fast. It's not something you can tack on at the end—if you want something to be fast, that has to be carefully considered from the very beginning. By the time people notice something is too slow, you're burdened by half baked architecture and a monstrosity of a codebase. At that point, it's near impossible to really make anything fast.

The likelihood that people who created Electron don't understand caches or cache locality is close to zero. That's an oversimplification. Electron is a large project that does many things… there are many reasons why it could have been slow. Today there are many Electron based apps that are quite decent.

Knowing how to maximally exploit a CPU is way more important than knowing eight different Javascript frameworks if good software is your objective. And frankly, learning Node is way easier than figuring out how to structure basic, bare-bones Javascript so that it leverages your L1 cache.

Learning Node isn't easier than learning how to structure basic, bare-bones code that leverages L1 cache. In fact, it's quite the opposite. You can learn cache locality as a concept in much less time than you would learn Node (or any programming ecosystem for that matter).

Possible. For me, it's a bunch of small things. I have three mailboxes. For one, search is almost always slow and incorrect. To the point where I usually have to load Gmail's web UI to be confident that I haven't missed anything.

It's strange because I like a lot of what Mail.app does—it's simple, no bells and whistles—but the search experience, etc. just ruins it entirely.

Mail.app on macOS. Some macOS apps are really great (Notes or Safari for example), but the average quality is poor. Mail, for example, is slow, search almost never works, etc.

Thank you, that sounds very reasonable!

How long did it take you to complete it on your own, including the exercises?

Things 3, it's a joy to use. I wish there were a mail app of similar quality!

Other than Things, the native Apple Notes app is great. It's simple, fast, and works with a fuss. Sync also seems reliable enough for me.

Not the OP, but I would definitely pay that.

I'm currently close to finishing their course on computer architecture. I'm self-taught; for me, it has been absolutely worth the money. I had learned a bit of architecture on my own, but the course has given me the kind of clarity that would have been very hard to get on my own. The syllabus is really good, it's practical, classes build up on previous classes. That gives you a solid understanding of all the components in a system. When I'd studied on my own, I spent too much time in specific areas that weren't _that_ useful for a software engineer. Oz himself is extremely approachable and the other students are really smart too.

Keep in mind though that it's ~18 hours of classes with ~3 hours of post-class and pre-class work per week. With any class like this, I've found that it's really important to actually do the pre-class and post-class work, especially the practical work -- it reinforces what you've learned in a class, helps you notice the gaps in your understanding and ask better questions.

I suggest everyone take a minicourse or read a book on systems engineering - at least the part where they discuss requirements. The fact that two distinct entities have an identical requirement for something does not mean there is one requirement. It means there are two requirements which (for now) happen to be identical.

I'd love to do this -- do you have any recommendations for a book like this?

Yeah, we were taught "learnt" in school (British English).

The Page Object pattern is common in Ruby (and some JS frameworks, like ember.js) too. I agree that the issues mentioned in this article seem mostly windows app centric. For JS apps running in the browser, the testing story is pretty good these days.

In my opinion, reading is more for shaping your thoughts over time. I generally don't read for recall value except for technical things, and even there, it's better to build a good mental model of the subject through a combination of reading and exercises, then use a book as a reference.

For non-technical books, I've very rarely seen any value in taking comprehensive notes (except highlights). I read those on a Kindle, so it's easy to highlight and reference highlights later.

Something I would love to see is how much it costs to keep some of these smaller startups running. Cushion app used to do this and it was really great.

That's a great question! If I'm understanding it right, I think the two ideas can complement each other. For broader goals or when you're totally clear what you want to do and how you get there, it's fine to take time. Even then, you can use shorter feedback loops to make the process more efficient.

Say you want to become a better writer. That's a broad goal and there are several approaches you could take towards that goal. On one extreme, you could read a lot about writing, write little, try to perfect things, and get something out once or twice a month. On the other extreme, you may write every single day and get it out in front of some people, get consistent feedback, learn, and improve. Both of these approaches will take time… the second approach, with the shorter feedback loop, can probably get you there faster though.

On some level, that is true, but when it comes to performance reviews and such, as the post mentions, it is very easy for your manager(s) to forget some specific things done over a period of time, forget their impact, etc. Even you may forget specific things that were done in a, say, 6 month period.

Besides that, it's also a good reminder for your own self to recap the work you've done in a specific period of time, notice your growth (or lack of any growth), etc. I've personally seen pretty good results with a similar approach.

This is one of my favorite blog posts of all time. It's applicable not only to just work work but a lot of other things, if you can shorten the feedback loop, you get a much better chance to improve the end result. It affects _everything_ else too.

This is a great post. The fact that you're bootstrapping is nice but I love how clear you are on why you're doing that and how it helps your business.