
Ask HN: What does senior front end developers do/know that others don’t? - RikNieu
I got talking with a colleague about this the other day and would like to know what you guys think?<p>What do senior frontend devs know&#x2F;do that others don&#x27;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?<p>Thoughts?
======
valand
\- readability > optimization

\- 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

~~~
quickthrower2
static typing is like a DB index, it makes code inserts a bit harder but code
updates and code selects a lot easier.

------
codingdave
These are good questions, but almost too vague to answer. If you have a few
decades of knowledge, it is difficult to pull out which pieces of your
approach to your work would be the most helpful to those getting started.

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.

------
Antoninus
I've worked and have been mentored by a lot of great engineers, they have a
few things in common:

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.

------
macando
|Harry Roberts - 10 Principles for effective Front-end Development|

[https://www.youtube.com/watch?v=8adsZeMQjGQ](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

~~~
sethammons
I'd like to hear more about not designing around edge cases and what that
means. Edge cases have to be accounted for, and accounting for them at design
time seems important.

~~~
quickthrower2
Not the op but I take it to mean avoid concrete concepts in code around those
edge cases.

For example in OO avoid making a derived class for a French tax calculation
for your one French customer’s invoice. I’m assuming here that your product is
not an accounting package and the tax issue is just for SaaS billing.

Instead make the design loose enough that this can be accommodated by data.
Maybe even manually enter their tax amount in a free text field.

But tying up the code for that edge case (and doing so for every edge case)
will lead to a complicated system.

~~~
macando
Pretty much this. It's especially true in startups where new features and edge
cases pile up really fast. Solve a new edge case manually in the beginning
(like adding a simple field instead of a smart calculation, like you
mentioned) and work from there. It might turn out, in a few months, that that
new feature nobody uses anyway so it's dropped. This is easier if you obey: 6)
Think at product level

------
typedef_struct
You've seen a couple of actual paradigm shifts, and the dozens of hype-cycles
in between. You can tell the difference between the two: what's important and
what's not.

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.

~~~
karmakaze
IANA FE-dev, but I don't think I've met many that fit this description. The
closest I can think of is to settle on an acceptable/popular framework (e.g.
React) and make it as pain free as possible (e.g. use TypeScript, clean
component patterns).

At the same time, current hype results in using React-Native for mobile which
seems feasible but short-sighted to me.

Maybe a better description is one who understands current trade-offs and makes
pragmatic choices rather than seeking future payoffs.

------
ThePhysicist
I think there's not a single list of criteria that you can apply. Some points
like a structured and logical approach to debugging have already been
mentioned. For me, a good indicator of a senior developer is the ability to
have an understanding of technologies beyond what's immediately necessary in
the day-to-day work. As an example, a junior React developer will be able to
follow a tutorial on Redux to build an app using flux as a paradigm, but would
probably not be able to implement such a system himself/herself using the
context mechanism and higher-order components (HOCs). Hence, when presented
with a codebase that uses such HOCs and context to manage state he/she will
quickly be lost if unexpected or hard-to-debug behavior occurs, unable to
resolve the problem without the help of a senior developer.

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.

