3 ms·

> A professional developer does thorough work when it matters, and cuts irrelevant corners that aren’t worth wasting time on. Extremely productive developers do

> A professional developer does thorough work when it matters, and cuts irrelevant corners that aren’t worth wasting time on. Extremely productive developers don’t have supernatural coding skills; their secret is to write only the code that matters. IMO the true mark of a professional, a truly talented, engineer is knowing which corners to round off before they cut you. Anyone can cut corners and leave the world full of problems for the next guy. But then the assumptions change. A queue gets really full, or we start needing utf-8 for emojis, or someone wants to rearrage the field order in a CSV. A great engineer would make a system that just works in those cases, because they can be (at least in go, node, python) implemented in just as many lines, just as complex of code, the only thing required is foresight (or its cousin, experience). Many will say YAGNI, but in my experience these things almost always come up (and I'm sure there are many others). Sometimes being a great engineer means reading between the lines of product designs, past sevs, and experience to figure out what the real feature ought to be.

arnorhs 2y ago
This is ambiguously stepping into "overly general / building for the future" territory. Perhaps that is not what you meant. There is a fine line where I do agree with you. Cases such as creating a relation table for categories, when you could have made a string array field instead. Or structuring a code in a way where you are not preparing for the future, but also not painting yourself into a corner. Examples such as that do come to mind. But as I said it's a fine line. This becomes exceptionally tricky when you are building towards a vision, but only 40% there, and having the code structured for that vision is hard to shake..
- Aeolun 2y ago
  It’s much easier in biz software, where what the customer wants is very likely the same as what everyone before them wanted, even if they haven’t come up with all the requirements yet.
- strken 2y ago
  The given examples of utf-8 support and reading headers from CSVs are things that (depending on stack etc.) can be nearly or actually free if you build that way from the start. I read the original post as saying something like "good engineers don't shoot themselves in the foot as much".
  - Vinnl 2y ago
    One challenge is when eg you're doing a code review and see that someone set it up with a non-utf8 column. In that specific case it's probably easy to fix, but it's still strictly extra work even if it hadn't been if it had been set up as such in the first place. I struggle with making that trade-off in terms of what's worth pointing out. Often what I'll do is point it out, but with an explicit disclaimer that I'm mostly pointing it out because it's good to know for the future, but that it's not a blocker (for larger chunks of work).
    - arnorhs 2y ago
      Yeah, that's the kind of tradeoff I have a hard time with as well. It's like .. well, you don't strictly need to.. but why not?

arnorhs 2y ago

This is ambiguously stepping into "overly general / building for the future" territory. Perhaps that is not what you meant. There is a fine line where I do agree with you. Cases such as creating a relation table for categories, when you could have made a string array field instead. Or structuring a code in a way where you are not preparing for the future, but also not painting yourself into a corner. Examples such as that do come to mind. But as I said it's a fine line. This becomes exceptionally tricky when you are building towards a vision, but only 40% there, and having the code structured for that vision is hard to shake..

Aeolun 2y ago
It’s much easier in biz software, where what the customer wants is very likely the same as what everyone before them wanted, even if they haven’t come up with all the requirements yet.
strken 2y ago
The given examples of utf-8 support and reading headers from CSVs are things that (depending on stack etc.) can be nearly or actually free if you build that way from the start. I read the original post as saying something like "good engineers don't shoot themselves in the foot as much".
- Vinnl 2y ago
  One challenge is when eg you're doing a code review and see that someone set it up with a non-utf8 column. In that specific case it's probably easy to fix, but it's still strictly extra work even if it hadn't been if it had been set up as such in the first place. I struggle with making that trade-off in terms of what's worth pointing out. Often what I'll do is point it out, but with an explicit disclaimer that I'm mostly pointing it out because it's good to know for the future, but that it's not a blocker (for larger chunks of work).
  - arnorhs 2y ago
    Yeah, that's the kind of tradeoff I have a hard time with as well. It's like .. well, you don't strictly need to.. but why not?