by lollipop25 on 9/29/16, 4:29 AM with 152 comments
But I feel like I'm always a step behind the rest. There's this guy in the team knows how to operate Amazon, or this guy who that knows how to use Spring, or this guy that knows how to scaffold a Java app in minutes. Sure, I can write in the Java language but I don't know Spring by heart. I can build and run containers, but I don't know how to launch them in the cloud.
When is one considered to be a "senior" developer? Is there a means to measure where I am? How do I get there?
by misframer on 9/29/16, 11:44 AM
Mistakes, rewrites, late nights, firefights, and deadlines.
Core dumps, memory leaks, hardware faults, and plain bad luck.
Big O, data flow, always learning -- or out you go.
Manager metrics, schedules hectic, methodology hegelian dialectic.
Taking the heat, feature creep, open office, uncomfortable seat.
Holy wars, revolving doors, carpal tunnel, all you can take? There's always more.
Fucking suits, random reboots, and the ever present "thousand language stare".
Oh yeah, pressure -- lots of pressure. And time, time, time.
Metric shitloads of time.
Time, man. You gotta do your fucking time.
by jkingsbery on 9/29/16, 1:22 PM
My experience is generally the people I recognize as having deserved the title don't _simply_ just code. Not only do they write code that works and delivers the feature in a timely manner, they make it so the next 3 features to come out in that area can be done quickly by junior developers. Not only do they code, but they make everyone around them better coders. Not only do they code, but they also think strategically about what the team needs to keep going two years from now. Not only do they deliver the project, they get everyone excited about delivering the project.
I once read someone say "there's a difference between having ten years of experience, and having the same year of experience ten times." Time is a factor, but it's also whether you've exposed yourself broadly and deeply to new technologies, approaches and experiences so that when you are in a new situation (technical or otherwise), you have patterns for how to deal (or the self awareness to know that you don't know how to deal). So, part of it is time, but part of it is spending that time wisely.
by lmilcin on 9/29/16, 12:19 PM
Senior developer is about wisdom as opposed to knowledge. Juniors may learn things quickly, but what distinguishes senior is that you can trust them to do the right thing which is not always technical problem.
I like to compare this to asking children a question that they don't know the answer to. Some children will feel they have to come up with some answer and some will say that they don't know.
Junior developers too frequently feel pressured to produce a result and they don't see how saying that they don't know something is making them closer to producing anything. Senior developers know from their experience that this is just as important to know when you don't know something as it is important to know things. They will not feel too bad about not knowing something because they know the alternative is even worse.
by astdb on 9/29/16, 6:20 AM
by TurboHaskal on 9/29/16, 7:18 AM
It can happen even with two years of experience.
by captn3m0 on 9/29/16, 10:21 AM
From https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin..., which is a really great read.
by peterkelly on 9/29/16, 6:06 AM
Our industry is way too obsessed with fashion... sooner or later you realise that most of the "new" stuff is largely existing ideas re-hashed in a slightly different form. Senior programmers realise this and can pattern match to understand the role of various new technologies, and learn the details if and when necessary.
How do you get there? You already are, you just don't realise it yet.
by jobvandervoort on 9/29/16, 12:15 PM
1. Technical Skills a. Great programmers: are able to write modular, well-tested, and maintainable code b. Know a domain really well and radiate that knowledge
2. Leadership a. Begins to show architectural perspective b. Leads the design for medium to large projects with feedback from other engineers
3. Code quality a. Leaves code in substantially beter shape than before b. Fixes bugs/regressions quickly c. Monitors overall code quality/build failures d. Creates test plans
4. Communication a. Provides thorough and timely code feedback for peers b. Able to communicate clearly on technical topics c. Keeps issues up-to-date with progress d. Helps guide other merge requests to completion e. Helps with recruiting
[0]: https://about.gitlab.com/jobs/developer/#senior-developers
by edw519 on 9/29/16, 12:21 PM
No, I'm not being snarky, so hear me out...
I've met and worked with many developers over the years and lots of them have become very good with technology and user domains, but still have struggled to "crack the digital ceiling". These are brilliant people who have achieved serious things, but are still not recognized by the big decision makers as "senior", whatever that means.
Then there are a select few who always get the big gigs, big money, and big reputations. Why? Because they best satisfy their customers. There are lots of non-technical skills that help them, but I think the biggest is their ability to separate the signal from the noise and zero in of the most important things to work on and to get them done. It's almost like they have "satisfiability radar". And this rarely requires any special technical or people skills. All they really have to learn is a good grasp of the technology, a deep understanding of the customer's domain and business, and the ability to get things done through others. And how did they develop them? By good old fashioned grunt work, whether digging into the bowels of the system or getting up off their butts and relentlessly going around finding out whatever they needed to know.
Once you've figured out the best thing(s) to work on to best satisfy your customers, got them onto the decision makers' radar, and found a way to get them done one way or the other, you are no longer a dev or even a senior dev. You're now a digital rainmaker, the most senior dev of all.
by scotty79 on 9/29/16, 7:00 AM
They were forced to offer me position of senior developer and no other company after that dared to offer me lower position.
by Steeeve on 9/29/16, 7:23 AM
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 developers. Can explain concepts on the fly to lower level developers and walk them through the development process in terms they understand. Takes initiative at learning new technologies.
by gibb0n on 9/29/16, 2:06 PM
2) When you get asked by the business to do something you question what they are asking and the motivation, and then determine the best course of action based on their motivation rather than delivering the specific task they asked.
That's it really, it's nothing to do with your coding ability but more to do with your mentoring ability and problem solving skills. This is what is valuable to your colleagues and the business. Any answer related to coding ability is missing the point, it's important, but after a few years most people are the same programming level - it's just some people can help at the team or business level which is what makes you senior.
by intellectronica on 9/29/16, 12:37 PM
More seriously, except for very big and very hierarchical orgs where tenure is overly important, people will tend to give you the senior title when your work is indispensable. To be indispensable you don't need to know by heart this technology or the other - you need to identify what are the things that bring the most value and work hard at delivering them.
by jakecarpenter on 9/29/16, 6:30 AM
Senior people have made the right mistakes, wasted weeks of time, and know what to avoid, what to embrace, and what to ignore. A senior dev can understand the requirements and figure out what is important and deliver something without a lot of external input.
by robotnoises on 9/29/16, 1:33 PM
So to answer the original question: it is impossible to know.
by kasey_junk on 9/29/16, 2:28 PM
To me the things that make a senior developer are: 1) you give them a project, even an ambiguous or large ones, and expect it will work out fine. 2) they have been around enough different situations that they likely aren't going to be thrown for a loop by new challenges. 3) they mentor their fellow less senior developers.
To get there you need 2 things: 1) bare time, you just have to put in the time 2) variety of projects - if all you have is a bunch of time on the same problem you are unlikely to have developed the breadth of knowledge you need.
by amcrouch on 9/29/16, 7:55 AM
As others have mentioned as a senior you can be left to implement changes without guidance, you will clean up issues as you come across them instead of leaving it to others, you suggest improvements, you make time to mentor and guide more junior members of the team, you know how to relate to muggles and you act like a team captain.
Knowing lots of different hosting environments and languages comes with experience. The approach you take to your role show's your all rounded skill set.
by mmirza984 on 9/29/16, 7:32 AM
To sum it up I will use .NET as an example, in my eyes when someone says I am a senior .NET developer I assume that she/he has: - used UMLs, - knows how to write proper OOP and understands SOLID, - can use MS SQL and some kind of ORM, - uses some of the testing frameworks (e.g. NUnit), - knows how to deploy application whether on IIS, or install it with ClickOnce for example. - know how to handle source versioning (TFS or whatever is your poison)
I probably missed a few things, but that's about it for me. If a senor doesn't have these skills I assume first that she/he has great knowledge of company business which would make her/him a valuable asset, or that she/he got lucky, or it's a crappy company :)
by philbo on 9/29/16, 9:34 AM
My 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.
by jkot on 9/29/16, 6:29 AM
- you are technically competent
- can handle design aspects of full stack (backend, persistence, frontend)
- have enough credibility and confidence to say NO to business people
- you can lead a small team of developers (2 to 5 people)
by source99 on 9/29/16, 5:40 AM
by wmu on 9/30/16, 7:21 AM
> But I feel like I'm always a step behind the rest.
Don't look at things in this way, low self-esteem is the worst you can get. There are always people better than us, but their skills and knowledge weren't conjured up. Even extremely talented people need time to learn. And if you don't feel like learning new things may make you better, why to feel guilty? If you're not a Java programmer, why to feel bad because you don't know Spring or other details perfectly? You wrote you do things fast and correctly. So you're better than, say, 90% developers who work slow and produce crap. :)
by aburry on 9/29/16, 12:18 PM
by z3t4 on 9/29/16, 6:15 AM
by SpendBig on 9/29/16, 8:59 AM
Our 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.
by BurningFrog on 9/29/16, 6:12 AM
Some times it's given to people instead of money.
Don't worry about the title. Worry about getting good at what you do, and an asset to your team and organization.
by dvcrn on 9/29/16, 6:37 AM
A solid general code understanding is also needed in my opinion. This includes things like using documentation over googling everything. If I pair with a senior and he types "golang how to do x" on every problem, I probably wouldn't consider him senior. (Not saying googling is bad. Just don't be a copy-paste-from-stackoverflow engineer)
With that, I also hate the term "senior engineer". I got friends with 3 years of work experience that are now "senior" because a company hired them under a senior position (basically more salary) and the companies after that just did the same because "well he already is a senior, right"? This also generates a strong in-balance inside the team with a hierarchy that shouldn't be there. I am usually advocating for getting rid of job titles and calling everyone just "Software Engineer"
I am now 6-7 years into my career and don't consider myself senior. When people in interviews ask me what my career goal is, I usually mention I want to be able to consider myself senior as the next step.
by gambiting on 9/29/16, 7:28 AM
Above that, it depends what you want to do. If you fancy managing people, you can be a team/tech lead, or if you don't, then there is the title of "expert"(only a handful of programmers who worked here 10+ years have those).
by fowlerpower on 9/29/16, 12:02 PM
They have to have the basics we all need as engineers simply to pass the interview process. The data structures and algorithms, Big O and be able to walk through systems they have worked on in the past and the trade offs they made and why.
Then on top of the basics I look for a few more things. Usually the understanding of multi threading, multi process, asynchronous programming is very different between junior and senior folks. I dive into distributed systems and see if they have any exposure. I dive into multi paradigms and how deep their knowledge is in their respective toolset they have listed on their resume.
I don't necessarily think you need to know multi threading in and out, or distributed systems in and out, or your tool set in and out. You certainly need to know one or two of those though. You need to have some body of work you can speak very well to, this is a huge indicator of seniority. Mentorship and all the other things that go with that help differentiate as well between junior and senior.
I don't think there is a hard rule anywhere. Different folks will look for different things and at least where I work those things I listed are very important differentiators.
by ilaksh on 9/29/16, 7:13 AM
by ta998877 on 9/29/16, 2:24 PM
by mping on 9/29/16, 8:33 AM
I 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.
by ghuntley on 9/29/16, 8:21 AM
by chx on 9/29/16, 11:58 AM
by k__ on 9/29/16, 9:44 AM
Since 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.
by jwaldrip on 9/29/16, 3:18 PM
by vassilevsky on 9/29/16, 7:29 AM
by stevesun21 on 9/29/16, 11:23 PM
The true power to make you senior is how you train your brain to think and abstract. This will boost your capability of design rather than just coding
by partycoder on 9/29/16, 7:11 AM
In my understanding, a senior engineer is an engineer that can contribute without the need for technical supervision.
Now, not requiring supervision is different to leadership. A senior engineer is often an individual contributor, not necessarily a team technical leader.
by aisofteng on 9/30/16, 4:54 AM
by jjn2009 on 9/29/16, 5:55 PM
by christouphair on 9/30/16, 5:06 PM
1 year later new and shiny will become the standard, there will be thousand of beginners and you'll be one of the few "senior" developers on that technology.
Of course you'll already be learning the new and shiny that will become the standard 1 year later.
by noonespecial on 9/29/16, 7:24 AM
by _Codemonkeyism on 9/29/16, 8:05 AM
Another aspect that seperates seniors is their ability to talk and present to senior or top management.
by sakopov on 9/29/16, 7:13 AM
by Prad on 9/30/16, 12:19 AM
by Nursie on 9/29/16, 11:45 AM
Seriously, I worked for a place where thay was the rule.
Titles are somewhat meaningless. Apparently I'm a consultant these days...
by chrisseaton on 9/29/16, 6:03 PM
by sigi45 on 9/29/16, 8:18 AM
by ohgh1ieD on 9/29/16, 6:27 PM
by DracheZahn on 9/30/16, 6:00 PM
by squozzer on 9/29/16, 7:23 PM
by known on 9/29/16, 12:50 PM
by balabaster on 9/29/16, 1:42 PM
Senior is the difference between keeping your eye on the big picture and helping to move your team forward to the objective in a timely manner to achieve the business objectives that drive the company forward. It's the ability to step up and lead your team when called for. It's the ability to make decisions balanced between what's technically right in the short and longer term without losing sight of the end goal.
Never forget that you're not paid to deliver software just to deliver amazing software. The software you deliver is a tool, a means to an end. That may be to cut costs, it may be to increase profits, it may be the lifeblood that your company's stock price hangs on.
A junior developer may be amazing with the tools provided and may have some good architectural sense. They may need some, or a lot of hand holding. A junior developer generally has their head in the code most of the time and may but probably shouldn't be expected to understand or care about the objectives of the business as a whole. You give them a feature to develop and can largely expect that they will need all of the dependencies to hand. They may have a good handle on debugging and unit, integration and functional testing or this may be something they need to learn. This is OK.
An intermediate developer can be given objectives regarding code and architecture and left to their own devices and trusted to deliver on their objectives in a timely manner. By this time, you should expect to at least understand the business objectives and be able to think critically about the code they're providing in order to meet those objectives. I would expect an intermediate developer to have enough of a clue about architecture that handed a feature requirement and some architectural direction for how to integrate it, they could architect it competently and integrate it and know where to go to ensure any dependencies are satisfied. They will have a good handle on debugging and at least unit and integration testing. They may have a good handle on functional testing and debugging production code.
A senior developer is someone in my mind who who can be trusted with the business objectives, can chase down architectural advice, from an architect or UX input or whatever else they need to get the job done; they can communicate effectively with stakeholders and the business; they can be expected to dig in and fill any gaps that would prevent delivery or cause problems in production. They can delegate pieces appropriately and deliver what is expected in the allotted time frame. They may be someone that can step up as team lead/team manager, or lead from the back and be the glue that gives the team cohesion. They can be expected to have the discipline to take care of things properly when nobody is watching. They can be expected to help debug production issues and be among the first to muck in when the shit hits the fan to help resolve production issues.
So you see, the difference between junior, intermediate and senior doesn't have an awful lot to do with code or tools. You will expected to either be or become a master of your tools whether junior, intermediate or senior. You will be expected to do this on the fly, on the job, regardless of everything else that is going on around you. This is part of being in this industry. You will be expected to keep up with the codebase and dig in and understand it at whatever level you're at. These are all prerequisites for your job as a developer, they are not a prerequisite for your title. There's a big difference.
If you want to make the jump from junior to senior quickly, here's my advice: Find the most gnarly difficult problems your company is having and dig in and help solve them consistently. When you've put yourself through the wringer; when you've suffered the late nights, the stress, the anguish about whether or not you've got what it takes to do this job. Do this until you get to a point where you think you've seen every last problem that could possibly occur, and despite that, something else hits you out of left field and knocks you clean off your feet. Do this until when this happens, you just get back up and keep going. When you get knocked down and get back up when everyone else would say fuck it, when you can be trusted to make shit happen when everyone else would say fuck it - this is when you can call yourself a senior developer.
"Out of the 39 000 men and women that make up the United States Coast Guard there are only 280 rescue swimmers. This is because we are the Coast Guard's elite. We are the best of the best. When storms shut down entire ports, we go out. When hurricanes ground the United States Navy, we go out. And when the holy Lord himself reaches down from heaven and destroys his good work with winds that rip houses off the ground, We. Go. Out." - Ben Randall, The Guardian
Live by example.
by pastorelli on 10/1/16, 12:40 AM
by navyad on 9/29/16, 6:22 AM
by anonymoose321 on 9/29/16, 6:09 PM
by supercoder on 9/29/16, 6:09 AM