
The role of a Senior Developer - mattbriggs
http://mattbriggs.net/blog/2015/06/01/the-role-of-a-senior-developer/
======
hamidpalo
This definitely is in the right direction, but leaves out a lot of very
important things.

I think of a senior developer as someone who is effective. Roughly that means:

* Planning: Ability to take on large, ill-defined problems, define them, break them up, and execute the pieces. A senior developer can take something big and abstract and run with it. They will come up with a few options, discuss them with the team and implement them.

* Execution: When something is planned a senior dev can execute quickly. They make tradeoffs, and they know why. They know where to be dogmatic and where to be pragmatic. They also can code well obviously.

* Communication: Effective developers are great communicators. They probably overcommunicate, gather feedback on non-trivial things, and thoroughly investigate feedback received. People often will say "give me feedback" but what that means is "tell me why my solution is right." For senior developers it's "poke holes in my solution." This can be very evident in pull requests -- junior devs can easily become attached to their solution, become myopic, and be unable to take feedback.

* Leadership: They are aware they're on a team. They view it as a part of their responsibility to mentor others. This can range from pair programming with junior devs, to taking unglorious tasks of writing docs or tests or whatever else needs to be done.

* And finally, they've been burned a lot. They can foresee where the problems will be before a single line of code is written, because earlier in their career they've been burned by a lot of things. An intermediate dev (or perhaps a junior dev) has been burned by poor spaghetti code, and has swung over to nailing everything with the GoF hammer.

Another thing that I have noticed how much of the above applies to senior
designers as well.

------
room271
Something that I think gets missed often from these discussions is the idea of
different definitions of 'senior' in different contexts. If you're working at
Google on search algorithms, it doesn't matter how good a communicator you
are, if you aren't technical enough to understand the work and think about how
to improve it, it's not much use.

Conversely, if you're a brilliant architect but aren't great at being very
pragmatic and hacking stuff out, you might not add much value to a lot of
smaller webshops.

So someone who would qualify as senior in one place, wouldn't be very
effective elsewhere.

And as developers, we can try and identify our own interests and skills and
find work that fits these.

------
Blackthorn
I know you admit that it's a gross oversimplification but this kind of talk
still bothers me a lot. It's a lot like when, to use a (honestly shoddy)
metaphor, people talk about rankings in a video game like League of Legends.
Some times you'll hear talk like "the difference between a bronze and silver
player is game sense!" or "objectives control!" or "mechanics!". The truth is
it's all of these things and none of them. A silver player is simply _better_
than a bronze player.

I think the same goes here. There's not some magic thing that a senior
developer has that a junior developer is missing. They are simply, overall,
better.

~~~
stuartaxelowen
> A silver player is simply better than a bronze player.

> There's not some magic thing that a senior developer has that a junior
> developer is missing.

"They're just better" is a way of saying "this is magic and not quantifiable".
If you cannot quantify what factors allow one developer to consistently
deliver quality software on schedule, then you cannot grow your team in that
direction, and are essentially rolling the dice.

~~~
dropit_sphere
That would be true if you were _programming_ your team, but what you're really
doing is setting the magnificent machine known as the brain on the problem,
which does all sorts of things we can't explain.

I'm all for figuring out explicitly how to deliver software better, but
pretending that implicit knowledge doesn't exist seems like folly.

~~~
stuartaxelowen
In a sense, you are programming your team, in all the things you emphasize and
spend time talking about at meetings.

Also, there are obvious things that make developers more able to deliver
quality software, and there are obvious things that make gamers more able to
win games, just as there are with famous athletes. Thinking that there aren't
specific predictors of success here is as silly as saying there aren't
specific predictors for what makes a good QB.

~~~
dropit_sphere
>In a sense, you are programming your team, in all the things you emphasize
and spend time talking about at meetings.

I'm saying that the analogy is just an analogy, and doesn't apply strongly
enough. What you're doing has strong components of feeding an ML algorithm
training data. Yes, people have intentions and can understand processes, but
that's as far as it does. We're certainly not writing neuroassembly.

I don't mean to imply that there are no predictors for better performance, but
I bet there are fewer than one might think. A lot of the factors interact in
discontinuous or nonlinear fashion, making it very hard to just draw
correlations and call it a day.

------
mrits
I overlooked the first "then/than", but a few sentences later you had another.

(make that 3 so far...browser closed)

~~~
mattbriggs
One of my weaknesses is being terrible at writing :-) I am trying to get
passed it. Thanks for the feedback, I think I fixed them all.

~~~
waterlesscloud
In that case... "get past it"

I have trouble with that one myself. :-)

[http://www.grammar-
monster.com/easily_confused/past_passed.h...](http://www.grammar-
monster.com/easily_confused/past_passed.htm)

------
bannerbschafer
What are some tactics you can use as a junior/intermediate developer in a
company with a lack of senior developers to mitigate the risks you discussed
and foster growth?

~~~
stuartaxelowen
One big one: talk with marketing and sales about marketing and sales things.
It helps you look into engineering from the outside, and see the other side of
the interface - it shows you the pain of missed deadlines, and the surprising
benefit of having that one extra feature. It helps you put real value to the
output, and gives you context for measuring the worth of things you're
spending time on.

~~~
mcv
Excellent answer. I think the real difference between a junior and a senior is
not so much in coding skill; some juniors are really brilliant coders and can
fix any problem you throw at them.

But a senior has more experience with the "why" behind the coding. What are
the requirements in terms of schedule, user experience, stability,
maintainability, performance, development process, QA, etc. A junior can be
great at one of these, but a senior has to take responsibility for all of
them. So you need to understand the needs of all the stakeholders outside the
dev team. (At least the basics; functional details deserve an expert of their
own.)

~~~
collyw
I think his point about over and under engineering stuff is spot on. I did
both earlier in my career, and I would say that my skill after 12 years is in
knowing the correct level of abstraction, and understanding the tradeoffs
between various solutions.

(Yet all the interviews I turn up to these days want an hour and a half timed
coding challenge to be completed).

~~~
mcv
I totally agree with you (and the article) on experience concerning the right
level of abstraction. I don't think there's a quick shortcut to learning that,
though.

I think an interview that focuses on coding challenges isn't really looking
for a senior. Point them to a junior that's more appropriate to their needs.

In most interviews I do, we do talk about abstractions and maintainability and
stuff like that. Although I have recently done one that involved a coding
kata, which was kind of interesting because during the kata we also moved
through a couple of (small scale) levels of abstraction while discussing them,
and particularly the appropriate time to abstract some stuff.

