21–30 of 33 posts
Earlier quoted context omitted.
You're confusing the reality with the trappings. That's... not the mark of an experienced developer.
Not at all - perception is reality. These items influence the the leaders' decisions on who is an experienced developer through their implicit biases.
That's something that experienced devs know is very clearly false. That make work with your manager, but it doesn't work with your code.
Earlier quoted context omitted.
Not at all - perception is reality. These items influence the the leaders' decisions on who is an experienced developer through their implicit biases.
> perception is reality. That's something that experienced devs know is very clearly false. That make work with your manager , but it doesn't work with your code .
Earlier quoted context omitted.
> perception is reality. That's something that experienced devs know is very clearly false. That make work with your manager , but it doesn't work with your code .
You aren't getting it - your manager is the one who decides if you're experienced, if you get that raise, etc. The use of the word "experienced" in this context is being used as a credential. Credentials are granted through authority. So yes, it very much is true. I would even say that if one doesn't understand the role that perception plays, then they clearly dont have much developer experience.
We're talking about the former - about actually being good at building software. You seem to be obsessed about talking about the latter. Fine, I guess, but that's not the discussion the rest of us are having.
Earlier quoted context omitted.
You aren't getting it - your manager is the one who decides if you're experienced, if you get that raise, etc. The use of the word "experienced" in this context is being used as a credential. Credentials are granted through authority. So yes, it very much is true. I would even say that if one doesn't understand the role that perception plays, then they clearly dont have much developer experience.
There is a difference between building software well and persuading your manager that you build software well. (The better the manager, the smaller the difference.) Some of us have had certain coworkers over the years that sharply illustrated the difference. We're talking about the former - about actually being good at building software . You seem to be obsessed about talking about the latter. Fine, I guess, but that…
"Show", clearly communicates that perception is a component of the question. Who cares if you're actually good if nobody knows it, potentially including themself.
As a senior dev, your end-users are more junior devs. And the product you’re building is the Api you give them.
So a good senior dev will do what good product people do. Talk to their users, find where their pain points are, make sure they have the most delightful experience one can have, etc...
It’s like senior engineers in car factories. They’re not building the cars, they’re building the robots that build the robots that build the cars...
My view is that senior devs do not roll out features for end users, they roll out features for other devs. As a senior dev, your end-users are more junior devs. And the product you’re building is the Api you give them. So a good senior dev will do what good product people do. Talk to their users, find where their pain points are, make sure they have the most delightful experience one can have, etc... It’s like senior…
It's features that are rolled out for end-users the ones that have the most visibility.
You say "programmatic & design qualities" but I actually think a senior developer is more productive because they enhance team health by creating vision, mentoring junior devs, and effectively articulating their vision. This ultimately is the difference: can you expand your productivity by setting the team's pace and get others bought into a vision on how things should be done? If no, you could be the smartest tech w…