HN user

dnoberon

166 karma
Posts8
Comments34
View on HN

Heard a quote I liked today.

“In order to be effective working at any layer of abstraction you must have in-depth knowledge of the layer below where you’re at”.

To be the most effective at AI assisted engineering (if treated as an abstraction layer) you need to understand how code works, behaves, architectures etc. and what well performing, well built things look like. Doesn’t necessarily mean you have to know everything like you would pre-AI, but enough to be effective.

Not sure a personal attack against Jarred really helps the case for using Zig. He could have and should have focused on the language and not “a stinky manager”. Honestly, this makes me want to steer clear of Andrew as much as Jarred.

This reads even more like an angry teenager than my angsty high school diary. I'm not sure how many more strawmans and dismissive remarks I can handle in one article.

I can see that. Whether or not it's worth the time spent in setting it up is something I can't answer myself yet.

I think my biggest point further down is that you have to _already know_ that it's a bad idea - if you don't you can't instruct the agent to avoid it. What I see is so many more developers who just never get to that point now.

For many people in this industry this became the default when Google and StackOverflow appeared. Is AI really so much different there if you look at the root cause? I feel AI is just another tool for quick answers without investing time in understanding the problem. That mentality is not new and has not changed in decades with previous knowledge bases. Sadly.

Excellent point :)

We talked frequently but I always kept my reservations about continually moving up the ladder pretty hidden. It wasn't until this realization and acceptance that I finally was extremely open and frank about things.

Hi, author here. Just want you to know that there's a human being with thoughts, feelings, hopes, etc. on the other side of that article. My experience in life isn't worthless. While it doesn't sound like it was valuable to you, I feel like it might be valuable to others in the same position. So if you have some constructive criticism on the writing - I'd be grateful - but if all you have is vitriol and lack of empathy, just move on.

The title might be a little dramatic, but I poured my heart into this article. I had to make some drastic decisions and big changes with regards to my career trajectory - and if I can inspire others to be true to themselves, then I'll be happy.

I'm working on a metadata catalog aimed towards scientific data. After standing up an enterprise data platform/lakehouse for science and laboratories, I've been really depressed by the current offerings and the massive oversight they have when dealing with scientific data. So I thought I'd change that. We're targeting not only the right kinds of data, but also connectors/integrations that reflect where most science data lives at these labs.

Location: Idaho

Remote: Yes

Willing to relocate: Yes (except to Seattle, CA, New York, Florida or Texas)

Technologies: Rust, Node.js, Go, Vue, Azure, Big Data Tools

Resume: https://drive.google.com/file/d/1R3YWdfAd_aYqQ8BzCNNx1RXr_77...

Email: johnw.darrington@gmail.com

I'm currently working as an architect for the Idaho National Laboratory. Looking to broaden my horizons - literally. Hoping to find something that can get me and my family out of Idaho.

I've worked on big data systems and management for a while, helping write a custom data lake for INL in the process. I've managed teams and projects at various sizes. I'm hoping that I can make a difference somewhere and build a great product and team.

[dead] 4 years ago

A few times I’ve found myself stuck as the subject-matter expert of an internal project, or stuck in a role that I was growing either bored or frustrated with. If you’ve found yourself stuck as “the frontend person” and wanting to move on from a long-lived project, here’s some advice that might help you break out.

There's another comment that makes the same observation about the senior title on the resume. It's almost like the first thing you have to figure out when talking to a senior engineer is: title or talent? (I know talent might not be the best word, but it sounded neat. I also think talent doesn't refer to an inherent ability to do something but a set of skills developed over time to a high degree of efficiency)

"Unfortunately in 2019, the title of being 'senior' can be given to literally anyone (even with less than 2 years of experience) in their own organization but elsewhere, they are equivalent to a entry-level coder with a heavily decorated CV."

This situation is one of the reasons I asked the question. The title is being overused imo - and assigned by management to developers instead of by peers or an actual technical benchmark.

"So my approach is more or less of a senior-software-engineering CAPTCHA test."

I love this quote, and will use it from now on :D

Personally I think the industry as a whole is fairly bad at judging a developer's skill level at anything past a junior level when it comes to hiring.