251–260 of 460 posts
do not burnout I know you are young and you feel like you're invincible. I know you can pull an all-nighter and work the next day just fine. We have all been in that situation and believe me, it is gonna take a toll at your performance ... and it could even trigger or help you develop some health issues in your life that can sabotage you down the line. Realize there's only so much progress one can do in the day. Stop…
Ask HN: Senior developers, what would you tell a younger you?
do not burnout I know you are young and you feel like you're invincible. I know you can pull an all-nighter and work the next day just fine. We have all been in that situation and believe me, it is gonna take a toll at your performance ... and it could even trigger or help you develop some health issues in your life that can sabotage you down the line. Realize there's only so much progress one can do in the day. Stop…
Aren't young people allowed to, well, be young though? When you don't go to nightclubs, don't have friends to call at 1am and can't play guitar in your 400sqft apartment with neighbors on all sides of the world's thinnest walls, is it a terrible thing if coding all day and all night on relatively minor problems to make somebody else five figures a week is your primary source of excitement? Does it not beat alcohol an…
My overall productivity was extremely bursty then–herculean efforts followed by barely anything at all. Now, years later, I'm much more defensive of my time, it's far easier to maintain a consistent flow of good work, and I no longer wake up in the middle of the night having had a bad dream about my code crashing.
It'll give you a lot of higher level things to think about as you're diving deep into your first tech stack.
Read the error messages. Reread them. Extract every piece of information from them. Never close an error popup without having read and understood what it means. Always read stack traces when you're blessed enough to have them. 100% of the juniors (and an awful lot of seniors) I've ever trained simply ignore those and then come ask for help debugging. 99% of the time, the explanation for their problem is literally the…
100% agree. Likewise, I think adopting a "how can I create a stack trace/error message" mindset is incredibly important. Can you add a breakpoint to a certain piece of code? Could you add a try/catch statement somewhere to catch the error? Far too often good engineers do not have an "active" mindset in hunting for stack traces/error messages, instead, they wait for them to fall like manna from heaven.
(Hopefully only in your development environment.)
On the slightly more negative side: everything management tells you that's not in an email will have "never happened" when it's convenient. When you have a conversation with anyone where you think a plan was verbally agreed on, before doing anything your first action is to go back to your desk, write it in an email, send it to them as confirmation and find at least 1 other person, ideally in your reporting line, whic…
Generating a followup email is stating your understanding and interpretation of a verbal conversation. Verbal communication is full of intricacies. Especially when communicating things like priorities.
Why did you spend so much time on that feature and not this one I think is more important?
Why did't you tell me that "minor" feature A was going to mean that this more important feature B IMO was not going to get done in time?