4 ms·

A bit snarky, but I would add - don’t read opinions from a list and take it as gospel. Adapt to the jobs you’re in, and you’ll develop your own opinions, but n

A bit snarky, but I would add - don’t read opinions from a list and take it as gospel. Adapt to the jobs you’re in, and you’ll develop your own opinions, but now with experience to explain why. Opinions are formed by getting repeatedly hit with the consequences of your (and other’s) decisions, and everyone just has to take enough hits till the pattern seeking area of your brain takes over.

BiteCode_dev 2y ago
I agree, and would say is equivalent to: > - There is no substitute for doing. Less tutorials, more coding.
- graypegg 2y ago
  Yes true. Mostly just opining on the “list of everything you gotta’ know” is a bit TOO concrete IMO. (As opposed to too abstract) I was quoting out of similar things years ago at the start of my career, “it should be done this way because X said it” didn’t help me at all. It feels like insulation against being called too junior, since, you can just wholesale adopt someone else’s list of ideas and you’re good. But making mistakes because you’re new to the career is precisely what forms the base of those opinions in the first place.
efortis 2y ago
I agree, form your opinions when you have enough information. For example, if you can’t decide between two data structures or tech, pick one and add a comment: // I’m not sure
FLT8 2y ago
Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not. There are roles I've been in where it's only been years later that the true impact of decisions made was actually apparent. I'm glad I hung around long enough to experience that.
- scott_w 2y ago
  I wholeheartedly agree with this advice and have for over a decade now. I think there’s something in the fact that you know you caused that that helps the lesson stick. Potentially you will understand the assumptions you had then vs now that allows you to clearly see the underlying lesson to take.
- BiteCode_dev 2y ago
  Skin in the game is important. I have a terrible programmer friend. He is better at creating actual products than most people I met because his livelihood is on the line: he makes money only from websites. So he is not living in the abstract idea of best practices, he had to make it profitable for the last two decades, with little resources to go by on top of that. And he does. After 10 years, he is still asking me how to write git commands. And I'm still learning from him to shed a lot of BS from my practices.
  - intelVISA 2y ago
    Being directly chained to the financial outcome of your works will have you dropping Scrum for Scheme real quick...
- mgkimsal 2y ago
  I've been called back to code long after I left an org, and have had to review my own code 10-12-15 years after the fact. Seeing both the positive and negative aspects of decisions having played out in the real world was something it's hard to get from reading, and I'd argue somewhat harder to get even if you stay inside the same org for that length of time. Staying on the inside, you'll rationalize a lot of the changes to the code, the team and org over time, and it may be harder to be more objective about the impact the code has had. I was quite proud of some decisions, but realized the negative long term impact of others. Trying to share that experience and whatever 'wisdom' or 'lessons learned' with others has been its own challenge in some situations, because you can easily come across as "the old person" who doesn't "get it" wrt to current trends. Some issues are evergreen and fundamental, but it's difficult for less experienced people to understand why some of these things are really core. I'm not sure there's much substitute for experience in many cases.

BiteCode_dev 2y ago

I agree, and would say is equivalent to: > - There is no substitute for doing. Less tutorials, more coding.

graypegg 2y ago
Yes true. Mostly just opining on the “list of everything you gotta’ know” is a bit TOO concrete IMO. (As opposed to too abstract) I was quoting out of similar things years ago at the start of my career, “it should be done this way because X said it” didn’t help me at all. It feels like insulation against being called too junior, since, you can just wholesale adopt someone else’s list of ideas and you’re good. But making mistakes because you’re new to the career is precisely what forms the base of those opinions in the first place.

efortis 2y ago

I agree, form your opinions when you have enough information. For example, if you can’t decide between two data structures or tech, pick one and add a comment: // I’m not sure

FLT8 2y ago

Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not. There are roles I've been in where it's only been years later that the true impact of decisions made was actually apparent. I'm glad I hung around long enough to experience that.

scott_w 2y ago
I wholeheartedly agree with this advice and have for over a decade now. I think there’s something in the fact that you know you caused that that helps the lesson stick. Potentially you will understand the assumptions you had then vs now that allows you to clearly see the underlying lesson to take.
BiteCode_dev 2y ago
Skin in the game is important. I have a terrible programmer friend. He is better at creating actual products than most people I met because his livelihood is on the line: he makes money only from websites. So he is not living in the abstract idea of best practices, he had to make it profitable for the last two decades, with little resources to go by on top of that. And he does. After 10 years, he is still asking me how to write git commands. And I'm still learning from him to shed a lot of BS from my practices.
- intelVISA 2y ago
  Being directly chained to the financial outcome of your works will have you dropping Scrum for Scheme real quick...
mgkimsal 2y ago
I've been called back to code long after I left an org, and have had to review my own code 10-12-15 years after the fact. Seeing both the positive and negative aspects of decisions having played out in the real world was something it's hard to get from reading, and I'd argue somewhat harder to get even if you stay inside the same org for that length of time. Staying on the inside, you'll rationalize a lot of the changes to the code, the team and org over time, and it may be harder to be more objective about the impact the code has had. I was quite proud of some decisions, but realized the negative long term impact of others. Trying to share that experience and whatever 'wisdom' or 'lessons learned' with others has been its own challenge in some situations, because you can easily come across as "the old person" who doesn't "get it" wrt to current trends. Some issues are evergreen and fundamental, but it's difficult for less experienced people to understand why some of these things are really core. I'm not sure there's much substitute for experience in many cases.