Ask HN: What qualities show that you're an experienced software engineer?
I was wondering about what programmatic & design qualities draw the attention of experienced engineers & developers and signal whether you're a novice or a veteran.
32 comments
1) You can anticipate complexity - the what, where, when and why of how it shows up. You are not afraid of it, but...
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?"
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?"
Knowing when to not over-design for the task you need: do you really need to spend an extra week to add generics and factories and extensibility to a service that will only ever do one thing and one concept, ever?
Do you know how to write testable or mockable code?
Do you know how to write testable or mockable code?
You say "programmatic & design qualities" but I actually think a senior developer is more productive because they enhance team health by creating vision, mentoring junior devs, and effectively articulating their vision. This ultimately is the difference: can you expand your productivity by setting the team's pace and get others bought into a vision on how things should be done? If no, you could be the smartest tech wizard in the world, I'm not sure you'd be an effective senior dev.
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.
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.
I've always wondered if a developer who gets shit done would be offended if I told them what they've done is shit.
Yes, they do get offended. I've done that before because the code was shit. I appreciated that he got it done faster than I would have, but I didn't appreciate that:
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).
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).
Really depends on how much trust and empathy there's in the team.. I say my stuff is shit all the time and am okay w/ others saying it too in the context of my team.
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
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
A person who don't see the value in senior engineers who aren't team captains isn't a good team captain.
Suggestions differ between theory and practice. As a JavaScript developer here is my experience, not my preference or wishes:
* 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.
* 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.
"A senior developer can develop a whole application from scratch by himself. Senior devs know about design patterns, architecture, automating testing, performance, security, debugging, bug fixing, testing, validation, etc. This doesn't mean they don't have questions or make mistakes, it means they know how to identify problems and where to find the right answers. That's why they are the ones who get assigned highly complicated tasks that require an exhaustive level of knowledge."
Source: https://lightit.io/blog/identify_seniority_level/
Source: https://lightit.io/blog/identify_seniority_level/
Fear.
In particular, fear of complexity. The perfect is the enemy of the good, to misquote Voltaire.
In particular, fear of complexity. The perfect is the enemy of the good, to misquote Voltaire.
I am deeply afraid of 3 things: complexity, obscolescence and code without tests.
My view is that senior devs do not roll out features for end users, they roll out features for other devs.
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...
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...
Unfortunately, that view needs organizational support. If the stakeholders can't appreciate the work done because their perspective is that of an end-user, then a developer is going to have difficulties getting recognized for that type of work.
It's features that are rolled out for end-users the ones that have the most visibility.
It's features that are rolled out for end-users the ones that have the most visibility.
I can throw an ambiguous business problem at you and you can reasonably solve it with technology.
Your seniority is based on how big a problem you can solve and how reasonable your solutions remain.
Your seniority is based on how big a problem you can solve and how reasonable your solutions remain.
Three things:
- 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
- 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 get stuff done with minimal supervision. You have solved different types of problems and can make the judgement of the best tech to use to solve a new, ambiguous problem.
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!
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!
It's a safe bet to inversely correlate quality of coder with SLOC.
I have some perl cowboys from the early 2000s I'd like you to meet
Knowing the right direction to go to build what needs to be built. If you don't know, knowing how to find out.
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.
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 how to start.
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.
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.
[deleted]
[deleted]
[deleted]
Using the right tool / pattern for the job, vs rather than hacking at it. Generally simplicity and lack of code I think show a veteran at work.
If you work in the finance sector... fancy new car, expensive clothes, offload all your home work tasks to others (drycleaner, lawn care, mechanic, contractors, etc). It's all about the prestige and reputation.
Edit: Nice to see my personal experience is considered worthless by the downvoters.
Edit: Nice to see my personal experience is considered worthless by the downvoters.
You're confusing the reality with the trappings. That's... not the mark of an experienced developer.
Not at all - perception is reality. These items influence the the leaders' decisions on who is an experienced developer through their implicit biases.
> perception is reality.
That's something that experienced devs know is very clearly false. That make work with your manager, but it doesn't work with your code.
That's something that experienced devs know is very clearly false. That make work with your manager, but it doesn't work with your code.
You aren't getting it - your manager is the one who decides if you're experienced, if you get that raise, etc. The use of the word "experienced" in this context is being used as a credential. Credentials are granted through authority. So yes, it very much is true. I would even say that if one doesn't understand the role that perception plays, then they clearly dont have much developer experience.
There is a difference between building software well and persuading your manager that you build software well. (The better the manager, the smaller the difference.) Some of us have had certain coworkers over the years that sharply illustrated the difference.
We're talking about the former - about actually being good at building software. You seem to be obsessed about talking about the latter. Fine, I guess, but that's not the discussion the rest of us are having.
We're talking about the former - about actually being good at building software. You seem to be obsessed about talking about the latter. Fine, I guess, but that's not the discussion the rest of us are having.
From the title (italics for emphasis): "Ask HN: What qualities show that you're an experienced software engineer?"
"Show", clearly communicates that perception is a component of the question. Who cares if you're actually good if nobody knows it, potentially including themself.
"Show", clearly communicates that perception is a component of the question. Who cares if you're actually good if nobody knows it, potentially including themself.
to invest whatever is necessary to get the team and the project over the finish line - not just my piece.