3 ms·

> 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

> 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.

deleted 2y ago
[deleted]
cj 2y ago
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.
duggan 2y ago
> 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.
- fragmede 2y ago
  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.
  - duggan 2y ago
    > 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).

deleted 2y ago

[deleted]

cj 2y ago

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.

duggan 2y ago

> 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.

fragmede 2y ago
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.
- duggan 2y ago
  > 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).