HN user

briansteffens

260 karma

https://briansteffens.github.io/

Posts5
Comments50
View on HN

There are some things that I think become more fun, like dealing with anything you don't actually find interesting. I recently made a quick little web app and I hand-coded the core logic since I find that part fun. But I vibe-coded the front-end, especially the CSS, because I just don't find that stuff very interesting and I'm less picky about the visuals. Letting the AI just do the boring parts for me made the overall project more fun I think.

WE ALL HAVE THE OPTION TO FIND A BETTER JOB!

For now most of us in this industry do. This is not a long term solution to anything.

Unions promote individual rights at the expense of the customer, product, and company.

Individual rights? It's collective bargaining of workers, no?

Ah, but you left out the first paragraph which clarifies the second entirely!

riverrun, past Eve and Adam's, from swerve of shore to bend of bay, brings us by a commodius vicus of recirculation back to Howth Castle and Environs.

And you'll just have to read to the end of the book to find out how the sentence begins.

Joking aside, I actually love this style of writing even though I get virtually no narrative from it. I read it almost like some sort of abstract poetry, letting my mind wander as the words go by.

Also, I find it reads a lot better out loud than silently: easier to notice some of the strange dream-like word mixes. Like `venissoon` kind of sounds like `very soon`. I only saw `venison` until I read it out loud.

That feels like a leadership failure to me. In that case you'd look at the Chief, the union rep, the Mayor and any other folks who can change the culture but don't.

Yeah, I agree 100%, and this is why the "few bad apples" angle falls apart. This is a widespread problem with the culture of many police departments. It's not enough to fire the murderers themselves, we also need to ask:

- Who hired them?

- Who trained them?

- Who supervised them?

- Who looked into the previous excessive force complaints and decided they weren't a problem?

Erlang/OTP is really cool and I found the Elixir language pretty reasonable and even nice but:

1. Elixir is still a pretty leaky abstraction over Erlang. In my experience it's not enough to learn just Elixir, I regularly had to dive into Erlang library source code to debug or answer questions. This somewhat negates the benefit of a small, stripped down syntax when you often have to learn another one in conjunction.

2. Maturity of ecosystem. This should improve over time but I've had challenges finding high quality libraries, especially for things like database connection drivers or making network requests. It's often hard to tell how well-supported or complete a library is and regressions were a regular occurrence.

3. Documentation. In practice I rarely found official documentation complete or even helpful (outside of big projects like Phoenix / Ecto). Even core Erlang libraries had surprising chunks missing. It's been awhile but I remember it being very hard to figure out what options were supported in Erlang's TLS wrapper. I ended up stitching together pieces from the OpenSSL documentation, Erlang source code, and lots of trial and error.

4. OTP overlap with other scheduling systems. This isn't a design flaw as much as a potential footgun depending on how you deploy Elixir code, but there is a lot of overlap between the cluster management support in Erlang/OTP and, for example, container orchestration in Kubernetes. Both support scheduling some concept of tasks, configuring redundant copies of tasks, detecting problems, and restarting tasks according to policy. Deploying an OTP application on top of Kubernetes (on top of Linux) results in 3 layers of OS-like task scheduling to learn, teach, maintain, and debug through, all with distinct tooling, terminology, and limitations.

All in all, I found Erlang/OTP to be a pretty interesting and compelling platform, especially for certain special purpose applications. If I ever use it again I'll probably skip the extra layer of Elixir syntax and write straight Erlang.

SF weather is unusually consistent and most days it's on the cooler side but not super cold, often a bit cloudy/overcast. If you like that (I do), the weather is great. If not, the weather will be bad almost every day.

Speaking from my own very limited experience, I think C++ can be pretty nice if you basically write straight C but borrow from the C++ STL. Smart pointers (std::unique_ptr, std::shared_ptr, etc), collections (std::vector, std::unordered_map, std::set, std::stack, std::priority_queue), and stuff like std::tuple and std::optional really make C feel less clunky without getting too gross.

I was interested in working at GitLab a couple years ago but the salary calculator changed my mind. It lumped all the cities in Oregon together which gave some weird results depending on which city you live in. I can't imagine how wonky the data gets internationally, and it seems like the fairness of your salary would depend on the accuracy and granularity of the data GitLab has for your particular region.

Coding interview books: how to use bit fields to save a marginal amount of memory while making your algorithm work only with values of n <= 64.

Wow this is cool and you did this really fast!

So you did kind of a functional style where each row represents an instruction being run with a full copy of the state of the VM at that point in time. Then each subsequent row is based on the state of the previous one. Am I reading that right? (I'm not familiar with Brainfk)

I wonder at what point the complexity of interacting security systems hits dimishing returns? Not trying to be negative, I'm a fan of how much power AWS gives you. But seeing how many systems have interacting security implications laid out in a graph like that makes me curious how far you can take it before it becomes difficult to reason about. Maybe the systems are sufficiently isolated and well defined that it's not even an issue.

One thing I found really interesting while playing around with gdb on a program with dynamic linking is that functions are linked lazily when they're first called. So rather than hooking up calls to printf/fopen when the program starts, those calls instead get hooked up through an intermediate table to jump into the dynamic linker's resolution code. The first time each dynamically-linked function is called, it goes through a process of looking up the symbol. Once it finds the actual address of the called function, it writes a jump to that resolved address over the spot in the intermediate table so subsequent calls won't repeat the lookup logic.

Pretty cool to watch it happen. The call lookup code in the dynamic linker involves a bunch of strcmp calls, which makes sense, but I still found surprising for some reason.

You can set the environment variable LD_BIND_NOW to make it do all these lookups at startup time.

It's so cool how similar the contents of the arith function are to actual x86 code. The relative offsets were also handled really cleanly.

I agree not to go into low level programming expecting a wealth of job opportunities to suddenly open up, but I wouldn't tell people not to go there at all. Not only is assembly really fun to play around with, I feel like I've gotten a lot out of the bits of assembly I've read/written. Even though I've never written assembly code for work, being able to read the disassembly in gdb has come in handy before. Also, a lot of the subtleties of C/C++ never quite clicked for me until I had an idea of how the generated assembly would work.

It's similar to learning a functional language. I have no idea if I'll ever use Haskell professionally but learning a bit of it has been a good way to see problems and logic differently. I think both assembly and Haskell have made me a better programmer, even if I never become truly proficient in either or use them directly in my job.