2 ms·

Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit b

Maybe, but the people I have worked with have been pretty heavily bimodal, especially by the senior level - many people in the "competent" bucket varied a bit but generally produced workable code (maintainable as well as works now). But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later. Most frustratingly, it does actually work for the current task so those outside the system will only see problems with the later devs to work on it.

Aeolun 3y ago
> But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later The longer I work on stuff the more I worry this is me. I thought it was the code coming before me, but the code after seems just as error prone.
- BigJono 3y ago
  There's a really easy way to tell. If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
  - hotnfresh 3y ago
    Seasoned pro-tier for that specific sort of problem is just batch-exporting to excel and letting it do the graphing, or hacking something up in Power BI or whatever.
    - throw555chip 3y ago
      One point to make about thrown together solutions, in the following video: https://www.youtube.com/watch?v=TmhQCQr_DCA https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32 he changes Units Sold column from Decimal to Whole Number. For the trivial example, it would probably be fine but it could also be a costly mistake in other scenarios.
- the_sleaze9 3y ago
  We all start from somewhere and nobody was born starting from perfect. First label your fundamental concerns. You cannot improve what you don't measure. Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again. Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about? Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk? Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.

Aeolun 3y ago

> But there is a distinct class of senior engineer that produces awful code that is hopeless to work with later The longer I work on stuff the more I worry this is me. I thought it was the code coming before me, but the code after seems just as error prone.

BigJono 3y ago
There's a really easy way to tell. If I say something like "I've got my sales history in a database and need to graph how many widgets I've sold over time", do you start thinking about concepts and code, or do you start drooling and typing "npm database npm graph npm widget..."?
- hotnfresh 3y ago
  Seasoned pro-tier for that specific sort of problem is just batch-exporting to excel and letting it do the graphing, or hacking something up in Power BI or whatever.
  - throw555chip 3y ago
    One point to make about thrown together solutions, in the following video: https://www.youtube.com/watch?v=TmhQCQr_DCA https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32 he changes Units Sold column from Decimal to Whole Number. For the trivial example, it would probably be fine but it could also be a costly mistake in other scenarios.
the_sleaze9 3y ago
We all start from somewhere and nobody was born starting from perfect. First label your fundamental concerns. You cannot improve what you don't measure. Error-prone code? First number the errors then classify the errors. Are your errors related to typos or do they come from not handling variable input gracefully? Now reduce your numbers by consciously finding typos, or by consciously mapping out just what inputs could possibly come in. Miss one? Write it down and never miss it again. Meetings? How many times do you get "well actually'd"? What specific areas do you get asked questions about? Coworkers? How many times do you get asked for help? How many times do you ask the same question -with or w/o a subtle variation- more than once? How often do you reach out to just shoot the shit? How often does someone approach you for water cooler talk? Or (more likely) you just _feel like you aren't competent. Having hard numbers will go very far in getting a more objective viewpoint there.