jb3689

I like this as reference. I haven't seen a design doc properly used for implementation in a long time. More often design docs are there to facilitate collaboration - here's the basis of conversation topics that are interesting; these are the things that matter most and here's the foundation for discussion so we can get aligned. It's all too easy for a team to ignore or TL;DR a design doc which goes on and on about things that don't matter, and that can become a problem for an architect trying to implementation which winds up going off the rails because no one actually read the doc.

“Don’t believe everything you read on the internet” seems like the golden rule we’ve all forgotten

"Do the work assigned to them" has multiple levels of abstraction. You could say it's the task level which would be entry level. You could say it's the project level which would be mid level. You could say it's the a service or domain which would be senior. Staff should be tackling org wide and cross-team issues. The amount of scope and clarity needed for a "problem" changes and gets larger in expectation and more terse in explanation the further you go.

Do people have fun building vim macros? Vim macros are awesome because they don't involve reading manuals, memorizing obtuse key commands which you never use on a regular basis, or understanding weird configuration lines - you just use the editor the way you normally would except you're hitting record. Vim's power is that I can be editing, notice I don't have something, make it in 2 minutes, and then get back to more normal work. At least try to understand the thing first before criticizing it?

Running tests is a good example: do you want to run them from your IDE or do you want to run tests in the terminal?

The IDE folks praise the simplicity of having one tool which can run tests quickly without requiring added context and with having other IDE features able to load test context quickly.

The terminal folks praise the modularity, at-will configuration, and transparency. You do things the way the rest of the community does which makes it easier to get support and debug when things go wrong. Tests become a small tool you can reuse in other contexts (git bisect, watch commands, CI)

Sometimes I feel like the only sane person in the room for not wanting to have to usher the LLM through phase by phase. Every time I need to choose the next skill or cat the next error is just a waste of my time that could be spent doing things that actually need my attention like making business tradeoffs.

Yeah, this is how it factually does work, but it’s not great. That’s why so many people are having to build custom tools to fill the gaps

You have a deadline and scope (of solution) handed to you from product/management. It’s the same issue now at work.

I’ve found LLMs very good at two things: 1. Recommending paths forward, 2. Following established architecture. Your job is to be able to treat the LLM and code as sheep

Why would you do anything else? It’s still faster than me doing it as long as I’m parallelizing. I can regularly get up to 5-6 things running in parallel at the moment with no downtime. I suspect by EOY I’ll figure out how to run more

$400 * 23 business days would be $9k. Sounds ballpark to me

A good interviewer won’t be looking for a single solution to the problem. I’d expect them to entertain the Google Sheets answer - it’s good signal that the candidate will consider what already exists in the world. I’d rather extend the problem: the team is spending considerable time iterating with manual entry, what would you do?

Distributed systems and probabilistic data structures really should be in every undergrad CS curriculum even if just in passing for the second

It irks me that these "just use Postgres" posts only talk about feature sets with no discussion about operations, reliability, real scaling, or even just guard rails and opinions to deter you from making bad design decisions. The author writes about how three nine's is multiplied over several dependencies, but that's not how this shakes out in practice. Your relational database is typically far more vulnerable than distributed alternatives. "Just use Postgres" is fine advice but gets used as a crutch by companies who wind up building everything in-house for no good reason.

The problem is that a lot of what is happening is within the executive branch's power and/or democratic. A nontrivial number of Americans support everything that has been happening. The expectation at a time like this would be that you have checks and balances working, but all other branches have yielded their power. I find that jaw dropping personally, but it's where we are. Midterms are happening soon and are the right place to disrupt congress.

On the other hand, no one cares about Velcro or Tupperware

100% agree. I am interested in seeing how this will change how I work. I'm finding that I'm now more concerned with how I can keep the AI busy and how I can keep the quality of outputs high. I believe it has a lot to do with how my projects are structured and documented. There are also some menial issues (e.g. structuring projects to avoid merge conflicts becoming bottlenecks)

I expect that in a year my relationship with AI will be more like a TL working mostly at the requirements and task definition layer managing the work of several agents across parallel workstreams. I expect new development toolchains to start reflecting this too with less emphasis on IDEs and more emphasis on efficient task and project management.

I think the "missed growth" of junior devs is overblown though. Did the widespread adoption of higher-level really hurt the careers of developers missing out on the days when we had to do explicit memory management? We're just shifting the skillset and removing the unnecessary overhead. We could argue endlessly about technical depth being important, but in my experience this hasn't ever been truly necessary to succeed in your career. We'll mitigate these issues the same way we do with higher-level languages - by first focusing on the properties and invariants of the solutions outside-in.

Where though? The only people I see moving around live in Seattle, SF, and NYC where there are tons of open positions

  Location: Boston, MA, USA
  Remote: Yes (In-office/Hybrid also fine if local; travel is fine)
  Willing to relocate: No
  Technologies: AWS, Linux, Programming (esp. Ruby, Go, Elixir/Erlang), React, Typescript, Databases (MongoDB, MySQL, Postgres, Redis, etcd, Kafka), Infrastructure as Code, Kubernetes, Data Eng (Spark, Trino, Airflow, Hadoop), Consul, Envoy
  Résumé/CV: Shared on request
  Email: [email protected] (Note: e-mail mask; will openly share e-mail in response)

14 YOE with experience leading teams. Currently working for a unicorn. Keeping details light here so I am not doxed, but I am happy to share openly in private. Looking to roles working in distributed systems, reliability, or infrastructure (esp. databases, streaming, data eng). Prefer working for companies which are in scale phase and which have some traction. Role must have technical leadership opportunities.

I really wish someone would have shared something like this with me in graduate school. Learning how to be a successful grad student took me too long to learn. In fact, I honestly didn't event learn it until I was done with school.

Makes me wonder if we’ll see more emphasis on loosely coupled architecture as a result of this. Software engineers maintain the structure, and AI codes it chaos at the leaf. Similar to how data engineers commoditized data via the warehouse

Musicians picked Monster because they were reliable and had an excellent replacement policy not because of brand ego. The Darn Tough of cables at least in terms of policies

> They did it within a system of laws and regulations that government admittedly does create for fostering such wealth creation. However, this still often requires strenuous effort by these people for their own ends.

You are confusing two things thinking they aren’t highly related but they are. This statement could otherwise be written “government created a flawed system and motivated individuals achieved wealth by taking advantage of that system”. That implies a flawed system was causal. We don’t need bigger government, we need the right government. No one wants to say that those who worked hard - even by benefitting from a flawed government - should not have high wealth, but by your same argument, what did the wealthy children of these individuals do to justify their wealth? Their children? How long do we believe this chain of inheritance is sensible?

I believe the previous poster was arguing that taxation still exists at a macro level, i.e. money is sucked out of the economy. It doesn’t matter so much who paid the taxes. The wealthy pay the interest.

Part of me wonders if doubling down on taxing transactions (which tariffs is categorically) can thus work. It seems like an elegant way to avoid having to deal with wealth vs income.

> Yes, the only thing that genuinely scares the rich is wealth taxes

Why though? We’ve already established the end game if we don’t do this. It’s hard to imagine society willingly regressing back to feudalism. What we likely need is a sensible plan which gradually adopts wealth tax rather than a radical step change.

That's the issue right? No one knows what access they have, so you should assume the worst. They've already been claiming that they are making writes, so full write privilege isn't off the table.

It's not even the access that's the issue though, it's the lack of oversight. If I login to a Prod database, my commands are logged which allow the team to go back and figure out what happened if something didn't go as expected. We have backups and response processes to deal with "oops" situations. I strongly doubt the DOGE team has any fallback plan, and it would be irresponsible to simply assume they've thought fallback through.

This is more troubling with the systems being tricky legacy systems. You might have the best intentions, but it is really easy to make mistakes in brittle systems even if you are careful. We've already seen evidence that the team may have no idea how to interpret the data they're seeing. It'd be reckless to start making edits while only having a partial understanding of the system.

The story from DOGE is "look at all this fraud we've found, we're going to fix it now". It's not "here's a bunch of things we want to investigate further". It's not "here's how we're going to test whether this is actually fraud". It's not "here's what we're going to try and how we're going to revert if we are wrong".

I’d like to see better controls for keeping diagram components from colliding. I’m sure that’s a nontrivial ask, but I run into poorly placed components quite frequently, and I feel like that’d be a major selling point for Mermaid for me if you could solve it

If you are doing anything serious, then yes. OTP is a top tier framework for writing any sort of complex parallel/distributed processing. I’d pick OTP over ActiveJobWhatever any day. Elixir code is also easier to maintain at scale due to stronger packaging and typing. OTP’s application abstraction is genius.

I searched for a guide explaining PID controllers the other day, and after the fifth full screen mobile pop up on a result I finally just gave up.

Even on your silly site I accidentally clicked allow because of the buttons switching to default positions I’m not used to.

Ah, the B type developer. Knows enough to find exciting and interesting problems but doesn’t know how to distinctly separate a type C (who can’t solve the problem at all) from a type A ( who knows the problem in and out and knows “it depends”). Not all that different to me from midlevel dev who learns about concurrency/metaprogramming/etc and starts using it as a tool for everything. Just enough to be dangerous.