Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Then there are engineers [...] who never try for the entirety of their careers

This matches my experience 100%. I am not a brilliant developer by any measure. I'm competent enough, I can put together good solutions to the admittedly low-scale problems I'm assigned, and I like to think I have a pretty good sense for the right and wrong ways of going about doing so. But I'm not even sure I could land an interview with a FAANG company, let alone a job.

My feeling at work is one of constant vigilance. I feel like if I look away for too long the gremlins will start creeping in. And I'm not talking about some imperfect design or the odd code smell, I'm talking about dropping in on a PR two senior engineers have already approved and spotting a critical security flaw in the first 30 seconds. Or a data loading pattern that works okay with the five records they've tested against but would make 300 database queries per page for a realistic dataset. Or spend 75% of their CPU time hydrating date objects from timestamps that are then immediately discarded.

I think it comes down to a lack of inherent curiosity and/or interest and/or passion in programming. To me good programming is a craft—I won't go so far as to say it's as much art as it is science, but I think there is definitely an artistic element to it. Which for me introduces a need to do something well, rather than just ticking boxes and going home. "Painting the back of the cabinet", as it were. If business requirements force me to ship some monkey-patch fix, it gives me a discomfort I can't really put into words. I immediately want to replace it with something better, because I just don't like putting work I know to be substandard out in the world. I'm not even particularly invested in the product and services my employer creates, but if it's my work I want it to be good.

Something I often hear is "I couldn't work out how to make <solution we all know to be good> work so I just did <sloppy solution that will need workarounds five seconds after clients start using it>". It irks to me to no end because without fail, what "I couldn't work it out" always means is "the first thing I tried threw up a minor roadblock so I stopped trying". And it sucks because the worse a codebase gets, the more difficult it is to contribute something you can be proud of.

Have I just had the misfortune of working at particularly crappy companies, or are things really this bad across the whole industry? I'd really like to think it's the former, but I read articles like this and dread that it's the latter.




An engineer I work with told me “I don’t think I’m a rockstar engineer, but I put care into what I do, and I think that makes up for not being a rockstar”

Even though she doesn’t realize it, she’s the rockstar on our team.

In your examples it sounds like your coworkers didn’t put much care into what they were doing.


You likely work at the top of the food chain in your IT structure as a result? You put care into your work and get results, people leave you alone?

I am the person everyone calls when things hit the fan, when disagreements need to be settled, when unfixable things need to be fixed, when something needs to be figured out. Do I feel qualified, never, no. I don't feel I'd last one day at say Facebook, no chance, I don't have skills to fit into a team, to play nice, the patience needed to grind the political structures. I like my dark corner.

Is it this bad across the industry? Its way worse, there are more people in the industry than ever, finding someone that actually knows something is impossible.

Build a book of people over 5–10 year period and never, ever letting go of them, keeping those relationships alive.


Pretty much hit the nail on the head.

Personally I do try my utmost on the patience and teamwork aspect. It might well be naive, and I’d much prefer to not have to, but I’d rather give the same feedback a dozen times, even if I’m despairing inside, than for anyone to feel like they couldn’t reach out for advice. Some of that is wanting to help my colleagues when they need it, some is the more self-serving point that if there is going to be a problem, I’d rather it be caught as soon as possible. Thankfully the company I work for is small enough that there are very little politics at play. There’s no risk of backstabbing or oneupmanship—if there was I would probably feel very differently.

Still, when I read the words “can we jump on a quick call” I know I’m not getting much done that morning.

> Build a book of people over 5–10 year period and never, ever letting go of them, keeping those relationships alive.

No worries there: while I lack both the skills and the personality to ever run a company, if I did somehow find myself in that situation I already have a small dream team of current and previous colleagues in mind. The sort of folks that are an absolute joy to work with.


> Have I just had the misfortune of working at particularly crappy companies, or are things really this bad across the whole industry?

It's not universal, but you might have to do a lot of searching. Personally, I think it's easier to find the right people in smaller companies, mostly because it's harder to hide in the crowd that way, but there are clever, dedicated people in companies of all sizes.

You'll do ok. Keep the fire burning, and keep looking for people who either share your principles, or respect them.


smaller companies are more exposed to customer demands. whether that makes for better or worse code depends on the team and company culture. the demand to ship something right this second and is existential for the company tends to prioritize shipping over well engineered code. At the opposite end of the spectrum, being totally insulated from such demands can lead to some really nice design docs, and code that might be the epitome of software engineering, but it also takes forever to actually ship anything because there's less of a forcing function, which also leads to complacency. there's a happy medium between the two that's optimal, though finding the right one is challenging.


> the demand to ship something right this second and is existential for the company tends to prioritize shipping over well engineered code.

This is a challenge, though very early in my career I learned that one solution to this is to just get better and faster.

Failing to deliver to your own standards becomes a motivator (with lots of caveats in regard to working environment, domain applicability, etc).


also learning to say no is an important skill to develop. my current director asks the impossible just to get us to say no, and then we have a good back and forth on what's a realistic balance, like what features we can trade off for which time.


I don't know if you're correct or not, but I will say your experience mirrors mine.

I have seen more than I'd like of people who throw some code at an issue without much interest or care or curiosity about it and think that's ok. A former manager of mine was always looking for people with, what he called, "the fire". I guess I had it at the time since he hired me.

There are places for devs without that, and I've been in places that suffered for trying to get ONLY those people too. But there are plenty of bootcamp graduates in it for the money or (what they thought would be) job security, and nothing else.


It sounds like you'd be a brilliant developer by most standards, but have the curse of understanding the gap between yourself and a top 0.0001% Linux kernel contributing supergenius. Drop my consultancy an email in case we do enough revenue in 2025 that we want to hire for 2026!


> Have I just had the misfortune of working at particularly crappy companies, or are things really this bad across the whole industry?

You’re just that good.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: