What do senior frontend devs know/do that others don't? How do they approach problems? What knowledge do they have? How do they interact with others? How much do they work? How do they support others?
Thoughts?
- investing for engineering excellency > paying technical debts
- preventing premature abstraction > code reuse
- interaction design is as important as UI design
- removed codes > added codes
- currently popular tool != the perfect tool for the job
- complex solution for a simple work != complex work
- being explicit > being implicit
- unfinished project will stay unfinished
- feeling the work less urgent actually lower team's morale
- team achievements > bean bags
- communicating technical problem and non-technical people is a sign of a mature engineer
- requirement gold-plating is as destructive as developer gold-plating
- adding engineers to a late project doesn't help
- delegating stuffs is actually a good exercise
- declarative is for structures, imperative is for stories
- static typing scales projects
- framework doesn't help if you don't know the fundamentals
- undefined is not a function
Likewise, presuming what other people do not know often comes off as arrogant, as there is very little in my knowledge base that someone with a couple years of experience couldn't know. The time put into this industry is less about specific tech knowledge or techniques, and more about having seen so many more things.
Situations that feel like new, huge new problem spaces for beginners may be something we can respond to with, "Oh, I did something like this 15 years ago. Here is how I did it then, let us see if we can do something similar, but modernize it with the new capabilities we have these day."
It is difficult to imagine every possible scenario these days and give a general answer that would be meaningful. My best general recommendation is to learn the concepts of deconstruction and reconstruction. Break down everything you do to its core components and concepts, decoupled from the technical solutions. Build your solution up from those principles, thinking of technology as a tool to solve problems, and not thinking of the tech as the solution in and of itself. When you approach problems this way, it is easier to make those connections in the future saying, "This is the same as the problem we solved a few years ago", because you recognize the underlying concepts.
1. They all happen to be a bit older 34+ (early 30s being the minimum)
2. They model their problems before writing code.
3. How they debug problems with a very workman-like, structured approach.
4. Write well and efficiently.
https://www.youtube.com/watch?v=8adsZeMQjGQ
Beyond languages and frameworks. One of my favorite speeches on development which I periodically rewatch. It will make you a better developer in general.
1. The simple option is usually the best
2. Reduce the amount of moving parts
3. Understand the Business
4. Care less, care appropriately
5. Pragmatism trumps perfection
6. Think at product level
7. Do not design systems around edge-cases
8. Do not make decisions based on anecdotal evidence
9. Don't build it until you've been asked for it
10. Expect and accommodate change
You've been up and down the stack enough to have a decent understanding of how things are implemented at the levels above and below the ones you work in. You can avoid the leaky abstractions in your stack and your abstractions don't leak on others.
The ability to have a good understanding of a large part of the abstraction hierarchy and, if necessary, leave the current level of abstraction is a good indicator of a senior developer, IMHO. Of course there will be more and less senior people, very few of us can go all the way down the abstraction rabbit hole (and it's usually not required).
So, another angle of this criterion is that a senior developer is able to work his/her way through a codebase without external help, solving problems on the way and obtaining necessary knowledge as required, whereas a junior developer frequently needs assistance from more senior developers to resolve unexpected problems.
Of course there are many other traits that I would attribute to a good senior developer, such as:
- Solid knowledge of fundamentals (HTML, JS, CSS). I've seen some junior developers get stuck implementing really simple designs because they lacked basic understanding of CSS and HTML.
- Understanding and taking into account the business problem that the software tries to solve. Senior developers understand - at least to a certain extent - that decisions they make when writing code affect the business outcome, and they will at least partially have this in mind when designing software. Junior developers on the other hand often love using all the exciting new technologies (which is understandable as they want to learn), but they don't see the bigger picture of the software in the context of the business.
- Ability to interpret, challenge and discuss requirements and assignments. Given an assigment e.g. from a designer or product owner, a senior developer will usually quickly recognize points that need clarification or modification and discuss those with the other stakeholders. He/she will also propose reasonable alternatives to requirements that would be hard to implement. Junior developers will often just try to implement everything you throw at them 1:1 without thinking too much about whether it makes sense. I've seen this e.g. when designers create layouts that are really hard to implement in CSS/HTML. A junior developer will spend days trying to implement the design, a senior developer will go to the designer and educate him/her on the issues of the design, trying to find a simpler solution that is easier to implement.
These are just my 2c, as I'm still learning myself how to recognize and hire good senior people.