HN user

paodealho

116 karma
Posts0
Comments33
View on HN
No posts found.

The last place I worked for, if it happened with someone new in the company or the team, I would find a polite way to say "do your job and fix this shit" and it worked.

Some people have put me on their blacklists after these interactions, sure, but they're the exact people I don't want to work with again. The important thing here is that I've never done someone else's work for free.

I like them. It tells very clearly how much effort went into someone's work.

I like them even more on code comments. It tells _precisely_ how much effort went into the pull request, so I don't spend time reviewing lazy work.

execs being misinformed about what their own companies are doing/achieving with AI

And a bunch of yes-men down the lower layers of management funneling these ideas.

In a meeting at my last job, one of the execs was bragging about how a chatbot was reading Jira customer service tickets and calling tools/APIs to solve those tickets, and it "only costs 1.5USD per ticket. How much would a human cost, huh?"

Little did the exec know, but my team was already using a ~600 lines python script to solve the problem with a higher rate of precision. The chatbot-automation thing was largely pushed by my manager when I was out on vacation, just so he could earn his good-boy points with higher ups. Worst manager I've had in my 14 years of career btw.

Fine doublespeak there. It can mean anything when talking to the public, and anything else when talking to Sam Altman.

And on that same sentence:

but in today’s world but in today’s world where the world changes every month, it’s best to be ahead.

Could I be the one getting ahead of him if I skip next month and plan for <next month>+1 world changes?

Goes to show how infested with disconnected management this industry is.

All the tools that improved productivity for software devs (Docker, K8S/ECS/autoscaling, Telemetry providers) took very long for management to realize they bring value, and in some places with a lot of resistance. Some places where I worked, asking for an IntelliJ license would make your manager look at you like you were asking "hey can I bang your wife?".

Software dev has been promoted as a good career path for almost 2 decades now. Naturally you'll have a bunch of people going in only because of money.

A few years ago, when Agile was still the hot thing and companies had an Agile "facilitor" or manager for each dev team, the common career path I heard when talking to those people was: "I worked as a java/cobol/etc in the past, but it just didn't click with me. I'm more of a peoples person, you know, so project management is where I really do my best work!".

Yeah, right...

It is my experience that most of these business domain experts snore the moment you talk about anything related to the difficulties of creating software.

... "Software Engineer," as a protected term. You can't just call yourself a software engineer.

In my irrelevant opinion, this is good. To me at least, the word engineer represents someone with a big, heavy responsibility on their hands.

I never liked being called an engineer and only have it on my resume because that's the keyword recruiters search on linkedin nowadays. One reason is that I don't have formal education. The other is that, in almost 15 years of experience, I witnessed very few occasions of software receiving proper care to the extent that I could call it "engineering".

I worked for a relatively large company (around 400 employees there are programmers). The people who embraced LLM-generated code clearly share one trait: they are feature pushers who love to say "yes!" to management. You see, management is always right, and these programmers are always so eager to put their requirements, however incomplete, into a Copilot session and open a pull request as fast as possible.

The worst case I remember happened a few months ago when a staff (!) engineer gave a presentation about benchmarks they had done between Java and Kotlin concurrency tools and how to write concurrent code. There was a very large and strange difference in performance favoring Kotlin that didn't make sense. When I dug into their code, it was clear everything had been generated by a LLM (lots of comments with emojis, for example) and the Java code was just wrong.

The competent programmers I've seen there use LLMs to generate some shell scripts, small python automations or to explore ideas. Most of the time they are unimpressed by these tools.

I have been thinking about this in the last few weeks. First time I see someone commenting about it here.

- If the number of programmers will be drastically reduced, how big of a price increase companies like Anthropic would need to be profitable?

- If you are a manager, you now have a much higher bus factor to deal with. One person leaving means a greater blow on the team's knowledge.

- If the number of programmers will be drastically reduced, the need for managers and middle managers will also decline, no? Hmm...

The git and systemd ones create several aliases for frequent commands:

git commit -> gc

git status --short -b -> gsb

git checkout -> gco

systemctl --user restart -> scu-restart

Nothing that you couldn't come up with yourself, but I've been using for so long it has become a standard for me.

The fzf plugin enables a fuzzy finder when you hit ctrl+r or ctrl+t. You need fzf installed.

I've been using it for the last 6 or 7 years and I can only remember one specific feature I use a lot: "unset HISTFILE" to disable history when I need to run commands with passwords.

Other than that, oh-my-zsh with git, systemd, and fzf plugins. Saves a lot of typing.

The main selling point for me is how easy it is to setup.

This gets comical when there are people, on this site of all places, telling you that using curse words or "screaming" with ALL CAPS on your agents.md file makes the bot follow orders with greater precision. And these people have "engineer" on their resumes...

There isn't anything clear until someone manages to publish measurable and reproducible results for these tools while working on real world use cases.

Until then it's just people pulling the lever on a black box.

Recently while interviewing for a SWE position, I was talking to the company's VP of engineering and expressed my concern over these LLM tools precisely because of the economics of it, because right now most if not all of these tools are being subsidized. Also, the environmental impact.

I was talking mainly about code generation tools, which can be completely shut down today without affecting production. Not even considering LLMs that are implemented in user facing features or customer service right now.

The guy's response: "oh but these things will surely get cheaper. Every technology gets cheaper with time. And about the environment, yeah... unfortunately there's not much we can do."

That's the level of forethought for a VP of engineering where I live.