jb3689

471 karmajoined 9 yıl önce

comments

20 saat öncediscuss

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)

geçen aydiscuss

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.

2 ay öncediscuss

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

2 ay öncediscuss

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

2 ay öncediscuss

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

2 ay öncediscuss

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

2 ay öncediscuss

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

4 ay öncediscuss

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?

5 ay öncediscuss

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

5 ay öncediscuss

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.

6 ay öncediscuss

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.

9 ay öncediscuss

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

10 ay öncediscuss

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.

11 ay öncediscuss

  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.

3 yıl öncediscuss

Whenever this happens, I really have to wonder about all of the people I call "good" on my team. Like surely someone gave a shit enough to know this is how it works, right? ...right?

8 yıl öncediscuss

To be fair, in my experience rewrites always take longer regardless of technology choices. You are often reverse engineering requirements which is really consuming both in time and energy. That said, I agree with the point you're trying to make though (I strongly prefer software with less dependencies/frameworks)