Preferences

dakiol
Joined 1,980 karma

  1. I feel divided. I do love my career (computer science/engineering) and I dedicate a lot of my free time to it (reading tech books, doing side projects, HN, etc.). But at the same time, I don't give a damn about my company. I hate the leaders, C-level execs, ... I cannot stand them, and it's not just my company, it's almost every tech company out there; so I work for the money, and take pride of my skills when working on open source and the like.
  2. I think the article mixes different things.

    > That’s the way we’ve always done it.

    That's not ego, that's laziness. At least based on experience, engineers are reluctant to change simply because they feel comfortable enough with their codebases.

    > Assign it to me. Nobody else will be able to fix it.

    Yep, that looks like ego.

    > This feature is too important to assign to the junior dev.

    Bad communication style perhaps? There are features that require a senior to drive them. What's wrong with that? Sure thing, I wouldn't phrase it as the author, but I don't see the ego anywhere. I see transparency and being upfront.

    > We should start using this new tool in our pipeline

    Again, perhaps it's just bad communication style. An engineer that says this is someone who cares enough to suggest things, even when nobody is asking. I know engineers who never suggest (or gatekeep) anything, they simply don't care

  3. LLMs subscriptions. Ideally I wouldn't need to pay for top-notch software (e.g., linux, ffmpeg, qemu, etc.), but here we are.
  4. Agree. I rather work with people who suggest stuff ("We should start using this new tool in our pipeline") than with people who ever suggest anything (typically they don't care).
  5. So far I've never seen yet a non-programmer release production-grade code using only LLMs. There's just so much to care about (from security, deployments, secret management, event-driven architectures, and a large etc.) that "just" providing a prompt to create an "app" doesn't cut it. You need infra and non-engineers just don't know shit about infra (even if it's 99% managed), you need to deploy your llm-generated code in that infra; that should happen in a ci/cd probably. And what about migrations? Git? Who's setting up the api gateway? I don't mean to say that LLMs don't know how to do that, but you need to instruct them to do so, and even there, they will make silly mistakes and you need to re-instruct them or fix it.

    Prompting is just 50% of the work (and the easy part actually). Ask the Head of Product or whoever is there to deploy something valuable to production and maintain it for 6 months while not losing money. It's just not going to happen, not even with truly AGI.

  6. Yeah exactly. I'm using codex, btw. So I feel weird to pretend I'm not using LLMs and I write all code just by using my brain. But on the other side, there's no much point on explaining one-self on how LLMs are used to do a task... like, it would look very ridiculous to share my screen and ask 90% of the solution to the LLM while the interviewer just looks at LLM output... that's like analyzing how one uses Google to search for stuff (and I swear that 100% of the engineers out there use Google to search for stuff related to coding, but I haven't heard of any tech interview that includes a session to asses your Google skills, right?)

    So, if we are not pretending, and companies want people who can use LLMs, well, I think it's rather clear: No more live coding interviews, no more live system design interviews. You can just send take-home assignments because people WILL use LLMs to solve them. You just analyze the best solution offline and take the best.

    If any the only "live" interview needed is: are-you-a-real-person-and-not-an-asshole?

  7. I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log).

    To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affected, and jumping easily to such versions).

    Git conflicts are easily solvable as well with a gui (jetbrain IDEs) via the cli or via something like Sourcetree. Easily, the most used "feature" of git that i use is:

    - for a given line of code, see all the files that were touched when that line was introduced

    But I usually do that via the IDE (because to go through dozens of files via cli is a bit of a hassle for me)

    So, what am I missing? I know jujutsu is much simple (and powerful) than git, but I only have used the "good parts" of git and it has never been a bottleneck... but ofc, you don't know what you don't know.

  8. It's not that complicated:

    - you review and if to the best of your knowledge you think something can be done better you comment about it and leave a suggestion on how to do it better

    - then you approve the PR. Because your job is not to gatekeep the code

  9. > I don't approve (and here's why) but someone else can

    That just sucks... because with that mindset typically nobody approves and leaves the submitter begging for approvals.

  10. > Tooling isn't the problem: The complexity is inherent to modern web development

    > Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application. Saying there are "too many" is an amateur take on the reality of the ecosystem.

    Depends. One can still write production-grade web applications with way less dependencies. You can write a Golang web server with minimal dependencies, keep writing CSS "like a peasant" and perhaps use jQuery in the client-side for some interaction. What's wrong with that? If you hire a strong team of engineers, they will be pleased with such a setup. Perhaps add Makefiles to glue some commands together, and you have a robust setup for years to come.

    But some engineers feel that counterproductive. They don't want to learn new things, and stick to what they know (usually JS/TS); they think that a technology like CSS is "too old" and so they need things like Tailwind. Makefiles are not sexy enough, so you add some third-party alternatives.

  11. I really didn't get what the post was about. I'm getting old or? And I thought I was clever because I work with distributed databases...
  12. I disagree. If we are talking about distributed systems in which we have N different databases, then distributed transactions are left as an exercise to the reader (that’s why we have things like Sagas).

    Within a single machine, yeah, relational dbs still work like a charm.

  13. That depends on what kind of “cheap” engineers you hire.

    If the SV engineers make 250K, you can hire: a) cheap engineers for 150K euro or, b) cheap engineers for 50K euro

    I can tell you that the engineers in group A are top notch, nothing to envy the SV ones… and yet they are cheap for american companies.

  14. > I’m rapidly losing interest in all of these tools

    Same. It reminds me the 1984 event in which the computer itself famously “spoke” to the audience using its text-to-speech feature. Pretty amazing at that time, but nevertheless quite useless since then

  15. There’s a fine difference between a) splitting a big feature in parts that interact with each other via well defined interfaces, and b) splitting a big feature in parts that are suitable for PRs

    You can split a big feature in N MRs and that doesn’t necessarily mean the N MRs are easier to understand (and so to review) than a single big MR. Taking into account the skills of the average software engineer, I prefer to review a single big MR than N different and not very well connected MRs (the classic example is that MR number N looks good and innocent, but then MR number N+1 looks awful… but since MR number N was already approved and merged the incentives are not there to redo the work)

  16. When salaries go very down. I love my career, I don’t necessarily like the jobs; but they are jobs and I maximise income (and free time). My salary is going higher over the years (I never earned silicon-valley-faang salaries to begin with) and it always puts me in the top 10% earners in the countries I have lived so far.

    If that stops happening, I’ll do something else (I’m preparing myself for this scenario just in case)

  17. As an user of the internet, I wish cloudflare didn’t exist. They are in most sites I visit, they add a couple of seconds of delay always. They can shut down entire ranges of ips if the government says so (no matter if some sites hosted in such ranges are legitimate).

    It sucks big time to live in an internet with cloudflare

  18. I think it’s mainly because of the year gap. Try lying about it. I had a 5 month gap in my resume (I quit my last job without having something new) and I got rejected a couple of times without having a single interview. As soon as I put that I’m still working, I got the interviews again on track. I don’t think it’s unethical to lie about that: if I pass their (shitty) interview, that means I “fit” their “culture”.

This user hasn’t submitted anything.