< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #286 - September 1, 2024

Here are the top threads of the week, happy reading!

Top comment by palata

When I solved a tricky problem for which I hadn't found a solution on StackOverflow, for years I got the habit of writing a question+answer on StackOverflow.

Until those started to get flagged (as duplicate, off-topic, whatnot) and closed. All of them I could make reopen (but it took time to collect the votes), and all of them eventually got a reasonable amount of upvotes and views.

That's where I stopped contributing to StackOverflow: when quality content I contribute gets refused by the moderators, I'm out.

Top comment by weinzierl

"A Philosophy of Software Design" by Stanford's John Ousterhout is excellent.

It is quite concise (about 190 pages), but in my opinion, it includes all the essential information that the other books in that category would teach you. It leaves out a lot of cruft that over the years turned out to be non-issues (code styling, problems that come with object oriented programming, etc.) but occasionally - when the topic is popular and widespread (e.g. Uncle Bob advice) - addresses them as alternative opinions. It was first published in 2018 and is therefore not in the out-of-date category.

So I would recommend it as essential read, hands down.

If you want something a bit more elaborate: "The Pragmatic Programmer" has a 20th Anniversary Edition. It is a timeless classic, worth reading at any rate.

That being said, I wish there was a single consistent resource[1] that summarizes truly modern software design philosophy in the sense that it leaves the object orientation inspired ideas behind that did not turn out to be useful and focusses on typed functional programming. Maybe with examples in Typescript and Rust.

[1] Possibly a book, but not necessarily. For me it would be important that it presents a consistent opinion, so it should be from a single author or small group of authors. The information I have in mind is mostly there, but spread out over many blog posts from people with slightly different takes and ideas about them. The overwhelming majority of recommendations in this thread are from authors I'd consider part of the founding generation. I'd love to read about software design from the perspective of a younger generation.

Top comment by lacksconfidence

I've also been at my current employer for a little more than a decade. I've been promoted to the 2nd highest level possible for an engineer without ever asking or doing specific actions to get those promotions. The last promotion would take actual direct effort, but I'm honestly not that interested. My salary is 2x-2.5x where it started as, and from a few brief stints interviewing at interesting places that reached out other people aren't willing to pay much more, and often less. We get a great work/life balance (wfh, 5 weeks vacation, 2 month paid sabbatical every 4 years).

I'm also very risk averse. I prefer being reasonably well known and trusted by the wider engineering staff here. I'm happy with where I am and have no intent of leaving. I mostly bring this up as a counterpoint to the people that say you can't have a good job by staying at the same place. Different places are different. Some of them are quite good. If you have a good thing, be willing to hold onto it.

With respect to not growing as an engineer, have you considered asking to switch teams or departments? I've shifted twice and each time led to a new set of challenges, but building upon my understanding of our systems.

Top comment by oulipo

Hey guys! We're engineers/designers from France, and we've built the Ultimate DIY Battery that you can repair and refill!

It works with 90% of the bikes/motor brands on the market, so I assumed that some people here might be interested, if they got a non-functional batteries but they still want to use their e-bike?

We believe that everybody should have control about stuff they own, and we should fight against planned obsolescence!

Here are a few videos about our founder on the battery itself, why we built it, and how to assemble it:

- What is the Gouach Battery: https://www.youtube.com/watch?v=NsuW1NPkvNk

- Presentation of the pack: https://www.youtube.com/watch?v=mLoCihE0eIA

- Presentation of the fireproof and waterproof casing: https://www.youtube.com/watch?v=EDJpt7RDbRM

Here are the juicy bits: https://docs.gouach.com

We'd love some feedback from the e-bike DIY builder community

Oh, and it's launching as a Kickstarter in September and there is an offer for early-backers here https://get.gouach.com/1 for a 25% discount on the battery!

You can follow us on Instagram https://www.instagram.com/gouach.batteries to get the latest news!

Top comment by Animats

Yes.

Languages

* C should have had standard types comparable to Rust's Vec and String. Pascal did. Null terminated strings were a terrible idea, and are still a curse. Plus a sane set of string functions, not "strcat" and its posse. Didn't have to be part of a general object system. Should have happened early.

* Slices. Easy to implement in a compiler, eliminates most of the need for pointer arithmetic. Again, should have happened early.

Those two alone would have eliminated tens of thousands of pointer bugs and decades of security holes.

Operating systems

* UNIX should have had better interprocess communication. It took decades to get that in, and it's still not that good in Linux. QNX had that figured out in the 1980s. There were some distributed UNIX variants that had it. System V had something.

Networking

* Alongside TCP, there should have been a reliable message-oriented protocol. Send a message, of any length, it gets delivered reliably. Not a stream, so you don't have issues around "is there more coming?". There are RFCs for such protocols, but they never went anywhere.

Databases

* Barely existed. This resulted in many hokey workarounds.

With all of those, we could have had CRUD apps by the late 1980s. That covers a whole range of use cases. There were client/server systems, but each had its own system of client/server interconnection. With all of the above, it would have been much easier to write basic server applications.

Top comment by nicbou

If I'm physically off, the most productive thing I can do is give myself space to recover. I try to refill my "Sims bars": sleep, eat, socialize etc. If I get bored, I might just clean the flat, triage my Downloads folder, and maybe pick some easy tasks from my to-do list. It gives me a clean slate for the next day, which really helps me recover.

If I'm emotionally off, I leave all work aside and take myself on a date. That usually means cycling to a breakfast place I like, going to a museum, getting drinks with friends or reading in a pleasant place.

Above all, I accept that not every day will be productive, and that forcing myself to produce consistent output is not a good idea.

Top comment by tworats

I've had great luck with graduate students (and sometimes even ungrads): I'll find a grad student who knows the topic, often by searching for lesser known content creators on youtube/blogs, and reach out with an offer to pay for their time to explain a particular topic. So far it's worked out great, and I've created relationships with smart up and coming people in the field - they make meaningful money, I accelerate my learning. I ended up eventually hiring one, and another did consulting for me for some time. We had a routine where I'd ask them to read and summarize / teach me ML papers that were of interest to me, which they in turn could use in their studies/thesis/youtube channels.

Tips on this: content creators tend to be more open to and better at explaining things, and you get to see their ability to explain before you pay them. If you can, overpay them - students need the money more than you do :-)

Top comment by fallinditch

I'm in the same boat, about to get stuck in to Cursor. But I'm wondering if it might be better to go with a VS Code extension like Continue.

With Continue you can use your own local copy of an LLM, and also query LLM API endpoints, so therefore better for a pay as you go solution and cheaper if you are a heavy user. Also you can carry on using VS Code as your editor of course.

This is my understanding of the trade offs. I assume that Cursor has better functionality and is better at coding for it to be a serious option compared with the VSCode extensions. I'm going to try out both and see what I like best.

Top comment by michaelt

In my experience:

1. There's very rarely a one-size-fits-all solution, in terms of what people need. Oh sure, if everyone needs a VPN then you should install the VPN and suchlike. If there's mandatory corporate security software, add that as well. But will they need docker? Will they need virtualbox? Will they need VS Code? CLion? PyCharm? IntelliJ? Do they need Java installed? Which version of Java? Will they need Altium? SolidWorks?

2. There's constant churn. You can't just create an image once and use it unchanged for years - there are so many components involved that there'll be some change or other needed pretty much monthly.

And you can't rely on volunteers helping out to scratch an itch - everyone in a position to do that has long since got their computer set up how they like it.

What's more, lot of the changes you end up pushing out will be unpopular. Ain't nobody going to volunteer their time to add a giant block of all-caps legalese to a login banner, or to deploy enterprise security crapware like crowdstrike.

3. Laptops are imaged by level 1 helpdesk workers. People who can troubleshoot Linux problems and maintain setup images probably aren't in helpdesk at all, and certainly aren't level 1.

So if you imagine making an image and handing it over to helpdesk to maintain - you'll find doing so isn't possible.

Top comment by throwaway2016a

The "hate" is for apps that only pre-package the GPT with a pre-written prompt and don't do much else. And the reason is, I think, because simply making a prompt template is usually not a significant enough value-add except for the most untechnical users. Most users can solve their problems just chatting with the GPT directly.

To get to the first part of your question: no. Every SaaS I've worked on for instance has included months if not years of creating intellectual property (often from scratch) so that the user's are receiving significant value over what they could do themselves.

Jealousy aside, I think they are poor business models because there is little to no barrier to entry.