|
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. |
Really want to emphasize the "read" part of this. It's an important learning tool. But also, that first year dev probably doesn't realize that it's a large part of the actual job. Maybe even the majority. You need to read other people's code because you need to be able to write code that interacts with it. You also need to read your own code from time to time, at a distance in time where you may as well be another person. Be sympathetic to the readers and be one yourself.