Ask HN: Senior engineers, advice for 1 year, 5 year and 10 years of experience

I am a Lead Developer, I haven't hit my 10 year mark, it's coming up in a few months.

-- 1 year --

Write code. Read code. Listen to other Devs. Start saving code snippets with a short explanation of what its doing. It will get easier, you don't suck, you are not bothering the Senior Devs as long as you show them you have done work and got stuck vs wanting to be spoon fed. Communicate clearly. For Sr Devs looking at your work, it's a lot easier to show them code that talk about code, they'll probably understand the problem and the solution better than your implementation of a solution. This is fine, as long as they are not prima donnas they won't mind.

-- 5 years --

1year + Pay attention to who the movers and shakers are. Cutting edge is good if it has a purpose, not just because it's new. Identify the best devs, look at their code, what are they doing that sets them apart? If you come across your code figure out what doesn't make sense to you anymore, what where you thinking when you wrote it.

Start paying attention to your mental biases. Sunk cost fallacy in code will be what trips you up.

Sunk Cost fallacy looks like this (fictional contrived example):

    Defect: Occasionally code fails for Integer number too large

    I will solve this problem with a function add(int x, int y) and it will make the code clear instead of x + y and check if the result is too big and throw an error

    Oh, but they use doubles once in a while, so I guess I will overload, two methods one for ints one for doubles

    Hmm, sometimes we have x + y + z, so might as well re-use my simple int add method, I'll just call it twice --- temp = add(x,y)  / result = add(temp, z)

    Well I might have the same with doubles just in case

    Create Merge Request. MR gets rejected, problem is not actually fixed, user still gets an error. The double method is making the code harder to read, and checking for DOUBLE.MAX_VALUE is silly since practically you will never have a number that large for the scope of the application. On top of that the code is much harder to read

What I am trying to explain is the common problem that plagued me as a mid level Dev. As you write code you keep trying to improve your solution instead of actually questioning if your solution makes sense based on your improved understanding of the problem. In general if I find myself doing a bunch of weird things, like a lot of if statements, nested for loops, calling more than a few methods to do something, changing an object too many times because I can't get everything I need from one place...mostly likely my design is wrong.

-- 10 years --

5year + politics now matter, you can choose to engage, disengage or ignore. All three choices have advantages and disadvantages. Personally I rather prove myself through code and with clear communication instead of trying to sugar coat everything I do. You should have already started mentoring other devs either officially or unofficially. Communicate clearly on how and when you can be disturbed. Time becomes more sparse when it comes to coding, treat it like gold. This is when you start communicating weird rules to people. Things like "only ping me via email", or "I don't respond to slack messages, I check slack once every 2 hours" become things. Others don't set clear boundaries and their code quality plummets.

What I am getting at is, you have to start making some decisions, do you want to stay a dev? Write code. Want to do other things? Start doing those.

Keep a journal of your work. Just a text/markdown-based linear note format. Try to free yourself from concerns about structure.

Well said. I would also add that if you start somewhere new, don't judge too quickly that everything is garbage there and you could fix it all. There are many layers of reasons/issues on why certain things have been done certain way and even though you may have better solutions, listen/learn first. Don't be a Know it all even if you are that good.

There's a chance this kind of person won't be promoted, or get to do fun things simply because they're so competent at doing hard things.

I think it's better to look like you're the type of person who can do that, but also look marketable and make friends with powerful people in the company.

Tell people when they did a good job, and mean it.

I'm not saying to gush over, but telling someone, "hey, you did a really good job with this, I like " seems to go over well with practically everyone. Even senior, domain experts like to be appreciated.

If you ever advice a person on a solution: follow up! Most people don't catch all of the bucketload of information you throw at them when they ask for assistance. Having a followup provides a convenient place for them to ask questions on stuff they forgot. I usually use this as a time to say good job (see above) and also ask what their next phase is going to be. Plus, following up lets you know if your advice was useful or not and helps you understand things more too.

If you every get advice from someone else, follow up!

Most of the respect I enjoy in life, both professionally and personally, comes from being generally appreciative of the people in my life. Turns out, people generally respect those who respect them.