Ask HN: What qualities show that you're an experienced software engineer?

* 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.

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.

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.

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).