From Dev to Senior Dev

#career #learning #webdev

I won't waste your time with a lengthy introduction, so let's dive right in: here are a few useful insights on how to become, or recruit a senior developer.

Product approach

A senior developer has enough insight and experience to say no and suggest iterations whatever your product might be. If you think something is suboptimal, it's your responsibility to say so. Sometimes, it's better to rethink a feature or completely ditch it if you think that the ratio between effort and ROI is not good enough.

Planning

Coding requires planning. Nowadays, whenever I start working on a new feature, I spend 40% of my time planning ahead. You've got to define a clear workflow: the product team defines a feature, the design team creates the mockups, and once everyone agrees on what's expected, you can start laying the foundations. For user flow, I like to use Miro. For Task planning, we create a dedicated Notion page where we can easily list and discuss the constraints, pros, and cons of the new feature.

Test-driven development

If I had to pick one key trait when it comes to senior developers, this would be the one. Testing is the best way to prevent regression, and the next logical step after planning your work flow.

I always do the same routine:

describe('my target component', () => {

  it('should do some magic stuff', async () => {

    // simply describe what you want to build
    userEvent.click(screen.findByRole('button' {name: 'my action trigger'}))
    expect(someStuff).toHaveBeenCalledTimes(1)
    expect(someStuff).toHaveBeenCalledWith({
      value: 'my value',
    })
  });
})

With every added test, I simply list the array of actions that my user might take when using the new feature. If everything has been correctly planned ahead, you know exactly
what to test, and what's supposed to be displayed at any time.

Special props to the wonderful

  screen.logTestingPlaygroundURL()

which allows you to render a testable playground of your app at any given time within your test.

Expect failure

In a perfect world, everything goes according to plan. But in web development, expect everything to go South. Whenever I build my tests, I keep an eye out for any potential unexpected behavior from my users. This comes in particularly handy when testing edge cases. For any given test looking like this:

it should submit form when properly filled

I've got a bunch of tests looking like this:
It should not submit the form when pressing Enter if a required field is missing
It should submit the form if non-required data are missing
It should disable the form if the submit request is pending

It doesn't take long to test, but then again, this prevents regression and ensures that your user experience is clean.

Proficiency

Last but not least, a senior developer delivers. At folk, we ship a new feature every other week, and each feature is assigned to a squad of two developers. We made the decision not to hire any interns/junior developers. This means no peer programming, quick reviews, clean code, and complete test coverage.

Tracking

A senior developer can easily raise red flags when something is going wrong. No need to be a data expert to know when something bad is happening, just set up a few alarms. I love using Datadog to keep an eye on our golden metrics, and we take some time each week looking at the graphs to make sure we keep our 99 percentile stats up.

Clean versioning

Once you start laying down your first lines of code, keep in mind these 3 simple rules:

Whenever you add a new brick to your feature, if it results in a stable app state, commit it.
Once you are satisfied with your code, run your CI locally, check if you didn't break any test.
If everything is good, write a meaningful description for your pull request. What are you solving? How to test it? Are there any interesting pieces of code? Add some screenshots/a screen capture if needed. Your goal should be to make the reviewer's life as easy as possible. Moreover, I like to use these rules when interviewing candidates. They have all the time in the world to solve our technical test, so the first thing I look at when checking their submission is the list of commits. Here are some of my favorites from recent interviews: