Well usually companies have their own view on seniority, and it could include how many years you have been there, but for what its worth for me a senior developer is a person who has experience with all stages of application development, which should imply that she/he can: - design and understand client/server architecture, - write code using best practices that is clean and maintainable, - knows database design and…
>- used UMLs Like unified modeling language?
Ask HN: When are you considered a “senior” programmer?
51–60 of 162 posts
Re: Ask HN: When are you considered a “senior” programmer?
#52Re: Ask HN: When are you considered a “senior” programmer?
#53Re: Ask HN: When are you considered a “senior” programmer?
#54When you are valuable and ask for a raise but they cannot give the amount expected because it's already Q4 so they give you the senior title instead. It can happen even with two years of experience.
If someone like Donald Knuth would be forced due to economic circumstances to join a trendy web start-up, he'd be a junior working under a twenty-something senior with little more than some Javascript and MongoDB knowledge. The whole thing's silly, really.
Re: Ask HN: When are you considered a “senior” programmer?
#55I consider senior someone who: - knows how to mentor juniors - knows his way around tech, even if he never used a particular product - most important, can communicate effectively with stakeholders and devs.
The best "senior" is the one who nags everyone to get stuff moving forward. Doesnt mind getting his hands dirty and going by people's desks to make sure the team delivers.
You may need to brush up your marketing skills in order to promote yourself as senior. Don't get impressed by people that know stuff.
Re: Ask HN: When are you considered a “senior” programmer?
#56My personal definitions: Junior: Can do it with guidance and/or clear and non-transitional specs Developer: Takes the ball and runs with it. Can walk a customer through requirements gathering and make recommendations. Will help guide junior developers. Senior Developer: Can architect a system well. Can communicate equally well between executives, salespeople, management, and end users. Can and will mentor lower level…
> Can walk a customer through requirements gathering and make recommendations Well yeah, I can do that, but isn't that normally the business analyst's job?
(Yes, I am currently frustrated with our product management)
Re: Ask HN: When are you considered a “senior” programmer?
#57Our senior developer is always thinking about the business value when estimates are made vs quality. He even does not do alot of softwae development, but is always asked to help out other developers, system engineers and even management to give advice.
To be able to do that in a professional way, your vision plus skillset makes you a senior imo. Not just the years of experience and amount of skills you have.
Re: Ask HN: When are you considered a “senior” programmer?
#58My main problem with thinking about developer roles in this way is that there's obviously no standard for what constitutes seniority. It varies between and sometimes within organisations. Advertising it, glorifying it, striving to achieve it, all take the focus away from far more interesting things that you can say about yourself and aim for.
Are you working on interesting projects? Are you learning new stuff? Are you being challenged technically? Are the other people on your team good developers? Do you enjoy what you do?
Seniority as an end in itself seems like a hollow objective to me. And making a big deal about it in a recruitment context takes the focus away from more meaningful topics.
Re: Ask HN: When are you considered a “senior” programmer?
#59sometimes these title can be dangerous.
Why?
Re: Ask HN: When are you considered a “senior” programmer?
#60Since I started programming my work-behaviour changed from asking people all the time when I don't know what's happening to reading their code.
I think developers are considered senior if they can work on their own.
Like, if you get all the engineering practices of designing, implementing and maintenance done without much help.