Ask HN: What non-technical skills make a senior dev and how to develop them? - poushkar
======
OliverJones
Empathy is the key skill. Yes, it's learned.

The ability to walk in somebody else's shoes for a while makes you a better
developer. Why?

* You acquire the habit of imagining what it's like to use the stuff you develop.

* You have a feel for the daily experience of your colleagues, suppliers, executives and other stakeholders.

These things give you the sort of spidey-sense that lets you function
independently. They also give you the ability to enlist other people to get
things done.

How can you learn empathy? Like any skill, it takes practice.

\--Listen to strangers. The question "what are you doing this afternoon" asked
at lunch will usually get an interesting response. Interject "wow" \- like
sounds to keep them talking.

\--Seek opportunities to meet end-users of your stuff. (Ask sales people to
take you along on calls if that's appropriate). Observe their work.

\--Ask your executives and project managers questions like, "what keeps you
awake at night?" And listen to the answers.

\--Teach. It doesn't matter whether you teach short courses or get a night job
as an adjunct professor at your local CoCo. Your interactions with students
will help develop your empathy.

People love to talk about themselves. You can take advantage of that to
practice empathy.

~~~
3pt14159
I've found "what'd you get up to this weekend" to be a great conversation
starter because most people have done at least one fun thing over the weekend.

~~~
CiPHPerCoder
People ask me that all the time and it's awkward. I very rarely do anything
anyone else would consider "fun", even on weekends.

Most of what I do can be classified as "work".

~~~
GrumpyYoungMan
Being somewhat similar, I sympathize. I just tell them that I spent the time
relaxing all weekend (regardless of what I actually did) and it seems to
satisfy people.

(In spite of the stereotype, I'm always surprised to see how few genuine
"introverted coders" there actually are in the industry and how unsympathetic
the rest are.)

~~~
tcdent
More people than you think follow this advice, which just leaves us with
misunderstood anonymous social interactions.

It's OK if you don't want to spend the time to explain the nuance of your
personal existence, but do understand that there is nuance in _everyones_
existence. Expecting that the other person you are talking to "won't get it"
is just blatant egotism.

Taking time to express what's important to you, and why, can be a very
constructive thing for those who want to listen. The OP advocates empathy, and
this is where it comes from. In my personal pursuit of empathy, I've had to
filter out responses from people like you, and try to see beyond the
untruthful statements in an attempt to understand what they are really saying.
Shyness is one thing, but a pattern of lies and deceit are indicative of
fundamental imbalance.

If you're having a hard time expressing why it's important to you, consider
introspection; is it really important to you? If you don't come away from a
day, or week, or weekend with _something_ to tout when prompted, I dare say
"you're doing it wrong".

I'm certainly not saying that I have something to be proud of every day, but
that I'm honest with myself when I don't, and will express to others that I
likely accomplished less than them in a given period. No lies necessary, and
the other humans around you are given an opportunity to see your similarities,
instead of some false iron gate of awesomeness.

~~~
iSnow
I am not sure you have a lot of empathy if you automatically assume people
want to be asked that question. I hate it if colleagues without kids ask me
about my weekend because I believe that the joy of fatherhood breeds extremely
boring stories for those who don't share it. I just don't want to feel lame
telling you about how cute my daughters were.

Or if I am bustling with joy because the wife and I managed to sneak in an
evening of kinky sex between bringing the kids to bed and work on monday.
THAT's what I am thinking about and THAT's not what I want to tell you. So I
invent some stupid story just so you are satisfied.

It's OK if colleagues which I know well and with whom I have a kind of bond
ask things like that. But not as a conversation starter or to create such a
bond.

And the list of people who cannot stand questions like that goes on: those
with depression for whom every weekend is just a period of grayness, those
with social anxiety...

~~~
tcdent
"That question" need not be singled out as an outlier; what we're talking
about is casual conversation.

Inventing a story, rather than truthfully explaining that you "enjoyed
spending time with your wife and daughters" sounds sick to me.

You have a bond with _everyone_ else already: we are humans. There is no
prerequisite.

As someone who identifies with both depression/anxiety and positivity toward
my accomplishments, in addition to a definite introversion, I reiterate my
last paragraph from above: stop lying to yourself and others. If you had a
simple weekend, where is the shame in admitting it?

If it was bad enough that you can't admit it, use that to fuel your
development instead of pacifying it.

------
mooreds
Depends on what kind of dev you are talking about. In a consulting shop
(enterprise or web dev or advertising)? Big company (software, hardware or
where software dev is an expense)? Game company? Silicon Valley startup?

Senior devs in each of these types of companies have some skills in common and
some that are particular.

The common ones, in my opinion:

* Ability to communicate with non technical folks

* Ability to estimate relatively accurately

* Willingness to do grunt work to raise team productivity

* Ability to work self sufficiently, own a big chunk of work, possibly leading small team

* Knowing when to raise an issue to higher ups

* Willingness and ability to mentor folks more junior

* Knowledge of the general software landscape for your domain, including what is buyable vs requires building

How to acquire?

* Seek mentors

* Always be learning

* Seek out folks outside of your department and learn what problems they face

* Attend conferences, technical meetups, or other online learning opportunities

* Help out

* Focus on solving problems and not on being right

Disclaimer: I have spent some time in larger orgs, but mostly as a contractor
so my advice may not be applicable for those.

~~~
OpenDrapery
Willingness to do grunt work is a fast track to becoming a manager who says "I
haven't coded in years".

No good deed goes unpunished. When you step up to be a team player and do that
grunt work, you open yourself up to getting more and more of it. Next thing
you know you have to stand up for yourself or become a door mat.

~~~
kafkaesq
If you're in an environment where rolling up one's sleeves and taking on the
grunt work leads so quickly to negative reinforcement loops, in the way you
describe... then that's a sure sign that you've found yourself in the wrong
environment.

In healthy environments (and yes, they do exists) good deeds are actually
rewarded, not punished.

~~~
enraged_camel
I don't think it's so black and white. In this case, the "punishment" isn't
literal. It simply comes in the form of more grunt work, which people trust
you with because you have taken it on before and did a good job with it. You
may actually be rewarded too when the annual review comes, if you know how to
spin it.

Furthermore, grunt work can be an excellent opportunity to shine. For example,
you can figure out a way to automate it so that the next person who works on
it (which may be you again) has to spend only a fraction of the time on it.
Things like running reports or generating documents tend to lend themselves
really well to automation, and a little programming ability can take you a
long way.

So yeah... think twice before turning away grunt work, even if you believe
that you may be given more of it in the future if you agree to take it on now.

------
jrockway
Generally, I see "senior" as mid-career, kind of based on how Google does
levels. (Engineering is basically "levels" 3-9, you get the "Senior" title at
5, so there is still quite a bit of career growth left after "Senior".)

Some things that you would want to start focusing on:

1) Figuring out what projects come next, and designing them.

2) Figuring out what your team wants to work on, so you can shape future
projects to be exciting to them. (We always have an infinite number of things
to do, so you might as well pick the things that are most interesting!)

3) Doing detailed designs, so that work can be parcelled out to people that
are gaining experience.

As you might guess, at this point you are doing more than working alone or
working on engineering tasks that someone else defined. You are defining the
tasks, and are starting to define the bigger projects.

Your individual contributions should be setting the standards for others that
work with you. Write that extra test, clean up that documentation, don't
launch a new service without monitoring. What you value will become what your
team values, by your example.

How to get to this point? Hopefully the more senior members of your team are
setting you up for success; allowing you to do some of these tasks until
you're good enough to do them without supervision.

------
tootie
I think everyone in this thread is wrong. There is one thing I look for any
time someone is looking to increase seniority in the organization and that's
ownership. How much responsibility can you own with minimal oversight? Will
you seek out the resources you need? Will you remove blockers. Will you do
what you say? Will you get others to help you? Some people do this by
producing lots of code and some of them do it by clearly documenting needs and
concerns and getting others to be more productive. Usually it's both.

~~~
rdudekul
Empathy can play a significant role in seeking the resources you need, getting
others to help you and perhaps even allowing higher management entrusting
responsibility on your shoulders.

Over the long-term though I found grit to be a more useful skill to cultivate.
Patience and perseverance sound like cliche, but in the end whether in
relationships or life, those count the most.

~~~
tootie
A lot of people are succsseful at this by being total jerks. Some
organizations show a marked preference for leaders who are aggressive and
abrasive over ones that show empathy. Usually bad organizations, but it
definitely varies.

------
combatentropy
\- Taste. Read _The Elements of Style_ and Paul Graham's
[http://www.paulgraham.com/taste.html](http://www.paulgraham.com/taste.html)

\- Watch _All the President 's Men_ and emulate the reporters Woodward and
Bernstein. They hustle. That's what I miss among people I work with. If
something is not explicitly assigned, cut-and-dried, and easy to follow, they
give up. You may not be fired, but good luck making a real dent in the
universe, as Steve Jobs used to say (another person to emulate! well, in some
ways).

------
m4r71n
A great read on this topic: [http://www.kitchensoap.com/2012/10/25/on-being-a-
senior-engi...](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-
engineer/)

------
mk89
In most companies I have worked for - or I had the chance to interview with -
ageing. :) So, just eat healthy, do some sports, and get older.

~~~
ramtatatam
Haha :-) Indeed, experienced people who had that perception. No grey hair? you
can't be senior.

Edit: I do not have grey hair.

~~~
mk89
My comment was a sort of provocation, but I see that some people seem to agree
with it. It makes me a bit sad, but unfortunately sometimes it's pretty hard
to change things - if at all!

The other comments are all relevant and very good, but they seem to overlook
one important aspect: the company's attitude. What all those comments have in
common is that they assume things work according to Tom DeMarco's book
Peopleware. I have learnt on my own experience that they don't. I have had the
chance to work with 1)poisonous, 2)negative, 3)defensive (see the
psychological meaning), and 4)offensive (... no psychology needed here) senior
developers. Some nicer/more experienced than others, no doubts, sometimes also
due to the lack of communication skills (English is not everyone's first
language, and I do understand it). However, these ones were senior due to the
number of years spent in the company OR their age. That's why I think that the
companies that value someone's skills (I like to see them like technical
skills, IQ and EQ) for their promotions are the minority.

~~~
marcosdumay
> What all those comments have in common is that they assume things work
> according to Tom DeMarco's book Peopleware.

This is a funny comment, since he keeps repeating through the entire book
phrases that sound like "you probably won't be able to get this for your
team", "you likely never seen it anywhere, but...", "when doing our research,
we've seen this. You might doubt it, but trust me, this exist on some places."

~~~
mk89
> This is a funny comment, since he keeps repeating through the entire book
> phrases that sound like ...

Yeah, I know. Of course I meant "things work according to the advises given by
the book ..." or something like that. I read the book, and everybody agrees
that "it's a great book, but in reality...".

~~~
marcosdumay
Oh, your comment was clear.

I literally though it was funny. Describing an organization type by the name
of the book that claims everywhere that it doesn't exist.

------
mknocker
Being the last man standing. Seems sad but when people leave bad company,
usually the people who stay get promoted and some of them become senior
developer. I have seen this strange pattern a few times.

~~~
humanrebar
Absolutely. A good way to make this happen is to crank out piles of write-only
code. You'll look more productive than your peers and you'll be the expert on
a relatively large part of the system.

When things inevitability go wrong, you'll also be the hero that powers
through the weekend hacking a solution together. Be sure not to document or
comment this code. It makes your memories critical to the operation of the
business.

Eventually everyone else but people like you will move on. You'll be given a
bigger say in the org by default AND you'll think exactly like all the other
senior engineers. This will make you appear to be good at communication and
working in teams since you can all say and do what you were already thinking.

~~~
mk89
I wonder if I actually know you and the user mknocker. Seriously, it's scary
to read this stuff for how real it is :)

~~~
mknocker
Good to know I am not alone :) There are a few pinpoints also to detect if the
company you are interviewing to is one of these. Usually, they are 'building'
a new team for an existing product. As I grew up in my career I started to
develop the reflex to ask why the previous folks left. You might not get an
honest answer but at least it gives you more information either you should
continue the hiring process or not.

~~~
spinlock
I just had a phone interview that was incredibly telling about the company.
The interviewer ... didn't speak english. And, I've been doing this long
enough that I embrace that broken english is the international language of
science. This guy didn't speak english. We had to communicate by typing into
the pair coding app (remember this was a phone interview).

Anyway, a company who puts that person on the phone as one of the first points
of contact has serious communication issues. It was an easy pass for me (I
already work in a company with broken communication).

------
christopherslee
To build on the suggestions other people are making, I would say that one
thing I look for in the transition from to "senior" is the ability to make the
people around you better. At the junior/entry level, a lot of your focus is
about consistent delivery for yourself. As you move up the ranks, its about
making you and your team better.

That could be removing roadblocks by flushing out designs and specs like other
people have mentioned, or finding better processes and practices to make the
team more effective. Of course, there is also the proper introduction of new
technology or techniques to raise the company forward as well.

------
jwoah12
* Ownership - being able to handle increasingly large tasks on your own with little to no involvement from your manager or lead.

* Search IQ - Nobody knows how to do everything in software development off the top of their head, but a major difference between a junior dev and a senior one is knowing what questions to ask and how to find the answers. I didn't used to have a name for this until one of my former mentees told me it's called "search IQ" in China.

* Understanding the big picture - At a junior level, you are generally able to understand your small task in the context of what behavior it should be producing. Senior devs should be able to grok development tasks in the context of the business use cases and within the wider system.

------
edw519
Whatever it takes to make money for customers. That's it.

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 make money for 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
"profitability 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 make money, 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.

~~~
maxxxxx
You are onto something but I think it's not directly about making money. In my
view you need to be able to talk the language of executives which is quite
different from how engineers communicate typically. If the CEO sees you as
somebody he can talk to you have cracked the digital ceiling unless you make
other mistakes.

------
alistairSH
I have the pleasure of working with both an excellent principal developer and
a principal test engineer (my other team members are great too, they just
aren't senior).

Both can effectively communicate with non-technical stakeholders. Product
Management, sales, consulting/services, clients, etc. I wouldn't hesitate to
include either in a discussion with executives (internal or client) when
appropriate.

Both can do any job on the team, including mine (project manager). They might
not be comfortable doing it. They might take longer on some tasks. But, if all
else fails, I can safely ask either of them to do anything and they'll find a
way to get it done.

Both have successfully managed special initiatives (in a "tech lead" role).
These typically involve coordinating across teams, so require a higher level
of time management and communication than developing for our primary project.

Both have successfully mentored junior developers, interns, or new (but not
junior) employees.

And Both have earned the trust and respect of everybody else in our division.
They are go-to resources, not only within my team, but across the division.

------
onion2k
All the 'soft skills' that other commenters have mentioned are definitely
useful things to have but they're things to learn when you want to stop coding
soon and move in to a more management oriented role. If you still want to
write code as a senior, learn to write _better_ code.

In my opinion a senior developer is someone who writes software that can be
maintained without their presence. That means less clever, impressive code and
more boring code that's simple and straightforward to understand that just
does what it's supposed to do. It means reproducible deployments. It means
tests which are up-to-date and working. It means everything is documented in a
way that a junior developer, or even someone non-technical, can get value
from.

In short, it means being organised.

------
ebbv
There's a lot of great specific examples in this thread but I think it all
boils down to this one quality; being able to put your own ego aside.

I think what lets a developer graduate from one level to the next is realizing
that your own knowledge, vision, etc. is limited and not always the right way
to go. Being able to put your own desires aside and execute someone else's
vision while still providing the benefit of your experience and knowledge when
appropriate.

Despite being a senior dev for a while now it's something I sometimes still
struggle with finding the balance on.

~~~
JonAtkinson
I agree with this to an extent, but a controlled burst of ego can sometimes
signal to the rest of the business that they're deeply off-track: "I/my team
are better than spending time realising this ridiculous
requirement/deadline/anti-feature, and we're just not going to do it. You need
to re-think this".

I don't recommend doing it too often (no-one wants a reputation for being
precious or difficult), but used correctly it can be powerful.

~~~
spinlock
I don't think this works in Silicon Valley. I'm a recent transplant but I've
found that people here are very passive aggressive and it's always a mistake
to be direct with people. Now, in NYC I never had a problem after talking to
someone about a disagreement (obviously in private). But, it's just not
affective in SF.

------
gt2
* Computer science fundamentals

To know the landscape and limitations thereof surrounding a product being
developed. These skills can be learned formally through school or informally
by continual pursuit, as many hackers find themselves doing who come from
backgrounds other than hardcore computer science.

* Communication

With stakeholders, the business folk that green-light and also those who
manage projects. This one is two part since it takes a good measure of both
knowing how to cut through the red tape and get the jobs done, and also how to
effectively communicate with them in the language they understand.

* Programming and devops

You need to know common idioms, a common framework or three, and the way web
applications are deployed and hosted. If you have programmed a ton of projects
over the years you will have seen firsthand enough of the wrong ways of doing
things to spot it a mile away and be able to know when something should be
refactored, rewritten, or not, and be able to review others code for the same.

I'm deliberately leaving off "people management skills" because I think #3
covers that -- managing the technical output of people is the most important
part for managing technical subordinates, which you will likely be at least
partially responsible for as a senior dev, even if it is for developers in a
mostly flat org.

------
orky56
Get your own work done. Be able to task yourself. Be able to task others. Fill
in the blanks with vague requirements. Develop an intuition to satisfy
stakeholders. Communicate transparently and with tact.

------
tmaly
I am the senior dev in our group. I think the biggest skill is being able to
teach. Yes you could be teaching junior devs tech stuff, but there is also a
lot of non-tech stuff that could be taught.

------
R3LL1K
A senior developer varies between different companies. In some companies, if
you are a senior developer, you start getting more client facing roles. So
your communication skills becomes more crucial. In other companies, you gain a
mentor kind of role where you assist your team in designing and developing
projects accordingly.

------
mathattack
1) Communication: Both verbal and written, both input and output, and both
logical and emotion-driven.

2) Proactiveness: Seeing issues before they happen, and acting on the right
ones when needed.

3) Ask for and giving feedback: Both formal coaching, and informally with
peers.

5) Starting with the End in Mind: Understanding why things are being done, and
doing things with the end customer in mind.

6) Planning and Estimation: Much harder than it appears

7) Bias in Decision Making: Understanding the flaws in how people think
(recency bias, overconfidence, anchoring, etc) and adjusting decision
processes to handle them.

1-5 is mostly by practice. There are books that can provide guidance on 6 & 7,
though there it's very much practice too.

It's also important to have good mentors every time one steps up in ability.

------
collyw
OK, not strictly answering your question, but for me its about being able to
give a developer any job and knowing that they can work it out. Development,
database design, server setup documentation. Being able to work on or debug
any part of the stack.

~~~
AndreyErmakov
Actually, this is the one reply in the entire thread that in fact answers the
question. This is how I see a senior developer as well.

In your professional evolution you start with simple tasks, learning to
accomplish them, first under supervision, then alone. Then you get larger
assignments and learn to work without hand-holding. Finally you learn to solve
all kinds of problems in your field of expertise with your chosen technology
and you get entrusted with making the right decisions and doing the good job
of it.

But then at some point it stops mattering what work to do, in what part of the
technology stack it is located, or even what technology stack this is. It
becomes a matter of simply learning what you need to know to perform the work,
doing it, closing this issue and moving on. That's what seniority means (or
should mean to provide a base of reference).

This is viewed from the technical side of things of course, and I believe this
is what the question implied. Good communication abilities and developed soft
skills are essential too but those transform a developer into somebody else to
whom the title of a senior developer no longer applies. They're no longer just
a developer but a higher-level product.

------
Clubber
There are two rules of success, one is soft, one is not:

1\. Do good work. 2\. Don't be an asshole.

------
peace011
Based on my experience at small companies and large corps, being a smooth-
talking B-player gets you more money and fame than being a great "hacker".
However, please, I beg you, always stay TRUE to yourself! The world doesn't
need any more zombies trying to climb the corporate hell, the world doesn't
need more arse-kissers, it doesn't need fake smiles and interest based
"friendships", and it doesn't need more conforming sheep. Stay TRUE to
yourself! Peace...

------
ScaryRacoon
Keys that I have seen: * Empathy, compassion, and passion * Ability to
delegate work appropriately and fairly * Ability to communicate in a
appropriate manner and at the appropriate times: * To the team * To management
* To non-technical stakeholders * Ability to identify the "unknowns" and give
a fairly accurate estimate that takes into account those unknowns * Know when
to raise the red flag if something big will hinder the original estimate * Be
humble (no work is "below" them)

------
steve_g
Domain knowledge about the business activities that your software is
supporting is powerful. Do you know why your users want what they want? Can
you suggest a better approach to solve their problem, based on your deep
knowledge of business needs? Do you know the impact of requested changes on
other parts of the business. This, of course, is very specific to a
company/industry.

Knowledge of accounting principles is often helpful for in-house developers.

------
hkon
Considering some people spend 1-2 years as "junior" and then 10-20 years as
"senior", you will get very different answers from "seniors" as they have
varying degree of seniority. Most points in this thread add value.

The one thing which in my mind make people juniors well into their 40's is the
inability to take responsibility.

------
mschip
There are a lot of comments here that are under the umbrella of getting old
and sticking with the same company which are probably true for a lot of subpar
companies. If you're talking about a good company that has a lot of good
engineers to choose from I would look for:

\- The ability to communicate clearly

\- The ability to understand team members with empathy

\- A unique penchant for foresight

------
itsjustjoe
Understanding the customer value of your work. This is one of the biggest
thing I see devs missing. Yes, developers are primarily responsible for the
'how' and 'when' for new features, but they should always be questioning the
'what' and 'why' as well.

------
mruniverse
* Know what's going on with the whole team (what state the project is in, etc) and be able to communicate it with anyone asking.

* Also be able to reach out to other teams to unblock issues.

------
Illniyar
Frankly, none. Everywhere I know of the position of senior dev is defined
solely by your technical expierence, and the screening in job interviews for
non-technical skills are the same for junior or senior dev positions.

Perhaps a better question is what non-technical skills do I need to work well
in a team (as a senior or junior dev), every developer needs to know how to
listen to people with different expierence and teach others about his own,
whether he's junior or senior.

~~~
kabdib
That's too bad. The senior devs I know are generally good with people: Making
them better, working out differences, getting people on-board with solutions,
helping one-on-one with things like code reviews and debugging sessions,
writing design documents, finding and fixing bugs that aren't theirs. The list
is endless. Oh, and they write code, too, generally lots of it.

~~~
collyw
I generally find that less experienced devs are the ones writing _lots_ of
code. Personally I think more and write less of it (and it usually works
better).

------
ejcx
A couple things that I think are important to being more "senior"

\- Owning the problem. Don't pass the buck when you see a problem and it's
well within your realm to own and fix.

\- Ownership and delivery. You have to deliver. You have to remove your own
blockers. You have to be realistic about what you're biting off. When you say
no, and you should, you need have a reason.

\- Be a leader. Make those around you better by thinking of them when you
build your system.

------
wahnfrieden
This pair of articles are surprisingly comprehensive, nuanced, and worthwhile:

[http://www.yacoset.com/Home/signs-that-you-re-a-bad-
programm...](http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer)

[http://www.yacoset.com/Home/signs-that-you-re-a-good-
program...](http://www.yacoset.com/Home/signs-that-you-re-a-good-programmer)

------
Everhusk
Understand exactly how development fits into the rest of the business, it will
vary for every company. The art of scalability is a good book to read to get
started.

------
caseysoftware
Someone who can teach/mentor those behind them.

That includes identifying useful ideas from elsewhere - conferences,
magazines, books, hn, etc - then adapting them to _make sense_ on current
project, convincing the rest of the team of their fitness, and then leading
the rest of the team to understand and learn them. Not a manager, a leader.

For the record, "make sense" is not the same as "cram every shiny v0.1 toy
into the next project."

------
codingdave
I think the other comments have answered the question well enough, but it is
worth noting that a title in and of itself doesn't mean much. I've had some
awesome titles in my career, from Senior Dev to Architect to CTO... but at my
current job, every single person here is at that level. So my title is just
"Developer".

Focus more on skill gaps, and less on titles, and you'll go where you want to
go.

------
e1452654a78d238
I would say a solid understanding of the fields that development most commonly
intersects with. Typically business (including politics), product, networking,
operations, and security. You don't need to be an expert but you do need to be
able to carry on intelligent conversations at the intersection points.

You don't need to be an expert but you do need to have a firm grasp of the
basics.

------
dccoolgai
Confidence. The ability to push back and stand up for the other developers on
the team and your craft.

------
fsloth
Take ownership of all of your actions and take responsibility for all
outcomes. If something did not work out do a root-cause analysis and try to do
better next time. Read "The mythical man month" by Brooks to get some
perspective to the daily problems.

------
chrisweekly
My colleague Elaine gave this interview on "what it means to be a senior
engineer":

[https://blog.codeship.com/elaine-uy-tapjoy-
interview/](https://blog.codeship.com/elaine-uy-tapjoy-interview/)

------
was_boring
One of the best resources for improving your soft skills is the book "How to
win friends and influence people". It's about 80 years old now, but still the
best work in its category. I keep a copy at my desk for quick reminders.

------
edburdo
Check out the book SoftSkills by John Sonmez.

[https://www.amazon.com/Soft-Skills-software-developers-
manua...](https://www.amazon.com/Soft-Skills-software-developers-
manual/dp/1617292397)

------
jamesbirchler
Being senior means taking responsibility for ensuring the right things happen.
If you can teach others to do the same, you may also be a project team leader,
and/or have the sensibility to be a people manager.

------
richev
Being able to teach others - focussing on the why, as well as the how.

------
darkhorn
Beard?

------
enry_straker
Age.

Grow old.

------
santiagobasulto
Faster, cheaper, better.

