2) You manage your time well - yours and others'. Figure out when complexity needs to be handled. Respect other peoples' time, they also have important things to do that don't involve you. While you could spend 1 month to figure out the answer to this gnarly bug in open source software after running strace and tcpdump and poring over the linux kernel source code...ask yourself - is this the best use of my time? The answer might still be yes. Just don't forget to look up every once in a while.
3) You prove your skill at 1) and 2) to yourself and others by empirically testing your decisions and evaluating the results.
4) You realize there are trade-offs to every decision you make. This sounds trite until you recognize that things that seem like no-brainers to you aren't, to others. This also applies to how you choose your workplace. Every place I have ever worked at has one really fucking annoying issue, but I have seen enough of these that I can rank them in preference.
5) You are aware of how others perceive you. Peer feedback on your performance should never be a surprise to you. If people were scheming against you, you probably should have known.
I guess after you feel comfortable with these things, you kind of stop caring about the answer to "am I experienced enough?"
Do you know how to write testable or mockable code?
A senior dev helps ensure the team is healthy. What's a good team?
- Do they get sh*t done. Do they deliver what they need to? Does it ultimately work?
- Do they work well with others. Do they serve their customers and stakeholders? Or are they perceived as a bunch of a-holes?
- Do they have a healthy mix of new talent/ideas and seniority?
- Does the team develop emotional safety and trust? Are constructive differences of opinion brought into the open, or is dissent stifled causing conflict to fester?
- Do they know what they're after? Have they self organized around shared culture, principles, and working practices for getting there?
A good senior dev is like one of the "team captains". The team captain is a top player that pushes the other players to produce, but also learns how to leverage and mentor fellow teammates in the game.
1. He wouldn't clean it up.
2. I had to clean it up (it needed to be kept around and extended).
3. He got all the credit even though his was an unmaintainable, unextendible (necessary for the effort, not just a want) mess.
4. I was the one who, after cleaning it up, actually made it a deliverable and added the critical missing parts (around extensibility).
If a random person emails me saying my code is shit -- not so well as I lack rapport w/ them. But, if random person emails me saying why my code isn't ideal and how I could improve, that would be awesome
* Know a framework and many of its supporting tools.
* Don’t spend any time learning the technology or how things work except where the framework dictates.
* Spend lots of time on code reviews instead of writing code yourself.
* When making changes do not refactor or improve the code. Keep the lightest footprint possible, as determined by your diff, to minimally complete the current business requirement.
* Don’t ever write original code. Use multiple NPM packages, or other code from elsewhere, to produce a solution. Software written by you or your team should be considered less valuable than anything you can find externally.
* Prepare lots of documentation for new hires. Defer all other documentation to project managers, information architects, and product owners.
* Don’t spend any time on security or accessibility until the layers tell you to. Most senior engineers just assume they are experts here anyways.
* The word innovation sounds important. Use that word as much as possible on anything that leaves the team.
* if a problem is too hard or requires something original you can always hire a contractor and then value them less for not being an employee and because they are foolish enough to write original code.
* Never be a contractor unless the employer is a sinking ship.
* When it comes to design that which is shiny always wins.
* Always remember less isn’t more.
I personally disagree with all these points. I have been a senior developer for many years, only because I can provide solutions others cannot, but my career is basically peaked unless I want to do something else.
In particular, fear of complexity. The perfect is the enemy of the good, to misquote Voltaire.
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...
It's features that are rolled out for end-users the ones that have the most visibility.
Your seniority is based on how big a problem you can solve and how reasonable your solutions remain.
- know all the tradeoffs and possible options you need to make
- have the judgement to balance and choose correctly
- be able to execute no matter the mix of choices
You have led projects, mentored team members, are the go-to person for something (could be a project, tech).
You are able to scope a solution in terms of time, # of devs, storage needed etc.
FYI, I'm launching a resume builder tool for tech roles and would love feedback! If interested please sign up at https://calendly.com/learnable-beta/uxr.
In exchange for up to 30 mins of your time, I'm offering 30 mins of ask-me-anything career coaching!
Writing fewer bugs. Trying to expose the bugs you've written. Checking on corner cases.
Handling errors rather than assuming they won't happen.
Naming things well.
Using appropriate languages, frameworks, tools, and coding paradigms for the problem at hand.
knowing what things to say no to.
knowing how to simplify.
knowing how to focus on the core that counts before everything else.
knowing that simple is not necessary equivalent to easy.
knowing how to separate research & development and not commingling them.
knowing how to keep going, knowing how to be unstuck when stuck.
knowing how to finish.
not falling for most new shiny things.
being resourceful with the things you have.
Edit: Nice to see my personal experience is considered worthless by the downvoters.
