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

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



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


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.


One point to make about thrown together solutions, in the following video: 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.


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.




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

Search: