< Back to the archive

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

Issue #176 - July 24, 2022

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

Top comment by skrebbel

Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps.

It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript.

When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a

    Map
but a

    Map>
This way, if a new, uncached key gets requested twice in rapid succession, ie faster than the computation takes, you avoid computing/fetching the same value twice. This trick works because:

- promises hold on to their result value indefinitely (until they're GC'ed)

- you can await (or .then()) an existing promise as many times as you want

- awaiting an already-resolved promise is a very low-overhead operation.

In other words, the promise acts as a mutex around the computation, and the resulting code is understandable even by people unfamiliar with mutexes, locks and so on.

Top comment by Apreche

I highly recommend doing what I have done most of my career. Get a job at smaller to medium sized non-tech company. Every company, in any industry, has computers. They need you. You don't have to work with a bunch of tech or finance people. You can get a job working with chill people in some other industry with a better culture.

When it comes time to negotiate, negotiate HARD. And not just for money, but especially time. Ask for so much that you think they will laugh or be scared away. If they say no, you lose nothing. Eventually the right opportunity will appear. I didn't think anyone would say yes to a 4-day work week, but I kept asking. Eventually someone said yes.

The one worry I am having these days is how long this strategy will remain viable. As SaaS and low/no code solutions proliferate, it makes little sense for non-tech companies to build when they can buy. This is especially true as engineer compensation continues to rise. Engineers who congregate at SaaS companies can build better products than a handful out on their own who are building a solution for just one company. Increasingly, the only engineers that non-tech companies need are people to manage their data, people to glue the SaaS APIs together, and maybe some frontend people to put a custom interface on it.

Top comment by Panther34543

I've given this advice elsewhere, and I'll give it here. Go look at the small business initiatives by each branch of the U.S. military; many are now posting lists of open contracts that you can bid on for an incredible array of things.

Browse through those lists and find something you can build.

I really believe the U.S. military is in the midst of a large scale transfer of military spending from traditional large defense contractors to smaller, innovative companies. The Air Force has even opened its own venture capital arm and is actively investing in small businesses. Most, if not every, branch in the military publicly posts contracts for small businesses to bid on.

I think Anduril is a great example of the possibilities in the "new" defense space.

What's interesting is this shift is very reminiscent of military manufacturing in Japan during World War 2; much of the manufacturing was actually done by small businesses of < 30 employees in "garages" scattered around the country instead of very large factories. That was one of the reasons American bombing by Superfortresses was so ineffective at first, and one of the reasons incendiary bombs began being used.

Happy to provide more detail on this. I've been thinking about this space for awhile.

Top comment by xena

I've found it worth doing. My blog (xeiaso.net, formerly christine.website) is the main way that I get employed at this point. It also helps that people link it here a lot. After 100 articles or so writing got a lot easier and now people rely on my blog for a lot of things. I think it's worth it, but I've also been exclusively self-hosting it. I currently have the code (and writing) open source on GitHub (https://github.com/Xe/site) but I'm considering moving the writing to either a private repo or a SQLite database because people keep copying it, slathering it in ads and rehosting it.

EDIT: also because independent personal blogs are a rarity now, having a decent one means that you can really stand out from the crowd.

Top comment by brightball

I’m going to go the other direction…it’s your responsibility to violate your childrens online privacy at least up to a certain age.

Block, restrict, monitor. Say no pretty much all the time. They’ll be fine.

There’s so much stuff out there where they’ll have no idea what’s going on but you’ll recognize it immediately.

NextDNS is great for this stuff. Apple Family Manager too. On a phone or iPad just remove safari entirely if you need to.

You’re their parent, not their friend. You can’t be both.

Top comment by busterarm

If you dislike going through interviews, I'm not sure that freelance work or going into business for yourself (which is the normal model for this kind of thing) is really the right answer.

When you're freelancing you're essentially interviewing for your job every single minute you're in front of or have an active project with the client. Soft skills and doing work that has nothing to do with engineering is even more of a requirement.

Top comment by sonofhans

Ooh, I’ve been doing nothing but this for 30 years. There’s other good advice in this thread, but my main advice is to pay close attention to people. UX is just applied psychology. If you understand humans well enough then you can create good solutions for them. It’s not surprising — you won’t create a good cat toy if you don’t understand cats.

1. Keep learning how humans use software. This is rooted in our physiology, psychology, and culture. It’s remarkably sticky across different contexts, and it’s learnable. Watch people using software; get them to talk about what they’re doing. You can do this in a lightweight way with coworkers — “Will you show me how you do X?” Then pay close attention and ask questions.

2. Prioritize task context and workflow. For the most part, UI design is not nearly as important as workflow. How does a user get from where they are to a solution? Whatever solution you design must meet the user where they are, where they have the problem. So be very sensitive to user context — as you watch people use software, pay attention to where they start, and what expectations they bring with them.

3. Document and maintain concrete goals for all design work. Before you design, write down a small list of goals in the user’s own language. “User stories,” we often call these. As you work, keep going back to that list to make sure that you’re staying focused on what users really need, rather than what you think is cool. As you use new software, try to reverse engineer this list of goals — “What were the designers thinking? What did they expect me to do here?”

4. Check your ego, and learn to love being wrong. Put unfinished work in front of people. Cheerfully accept all feedback without explaining or defending. Always expect that your design solutions are not good enough, and can only be improved by testing them with real humans. You are not your user; you must position yourself to be surprised by them, and to react well to that surprise.

Top comment by kokanator

Open an arbitration claim. Seriously.

The terms you agreed to states claims can be settled with arbitration. Opening a claim will cost a couple hundred dollars and will move them to action immediately.

Here is a great thread how this worked out for another person on HN.

https://news.ycombinator.com/item?id=31567673

Top comment by omega3

Especially since the removal of downvoting it's hard to get to good quality material. Majority of tech videos are a case of blind leading the blind and unless you know the subject already it's hard to spot.

Nowadays I start with a forum/reddit/discord/hn search for a list of hive approved creators and only then go to youtube with that list in hand. Starting the search in youtube (unless for a very niche/non-marketable topics) is close to worthless.

Top comment by ptttr

I do definitely recommend Clojure - I've switched to it in 2019 coming from Rails and JS and never looked back.

Clojure's job market is great, there's no shortage of offers, even for newcomers and it has been the top paying lang in stackoverflow surveys for years https://survey.stackoverflow.co/2022/#section-salary-salary-...

However, the most important part is that Clojure is a very powerful piece of technology that made me reevaluate what software engineering really is. You can efficiently use Clojure for both backend and frontend with easy access to libraries from JVM and npm so you will never run into the problem, common in other niche langs, of too few libraries. Nevertheless, Clojure's own ecosystem is filled with many great, cutting-edge ideas that you wouldn't find working so well elsewhere. The community is very welcoming, growing and diverse with people coming from all different programming backgrounds - all sharing the disillusionment with other programming languages and determination to find and build a better way.

https://jobs-blog.braveclojure.com/2022/03/24/long-term-cloj...