First days: Detroit & talk preparation

I got in three days before the beginning of the conference, both to give myself some time to explore the city and to better prepare and rehearse the talk I was giving.

Though I ended up doing a lot more talk preparation than city exploring, I loved the energy of downtown Detroit! The city sometimes gets a bad reputation (“isn’t that the city that went bankrupt?”, “don’t drink the water there!”), but my experience was very different. It was a lively city, with plenty of cafés, bars and attractions. Though as with many American cities, it’s not the most walkable. It’s the Motor City for a reason, after all.

The conference hotel was in the same building as the General Motors Headquarters, which explained the classic cars inside the building. The building was also notoriously hard to navigate, which at least gave an easy ice-breaker for conversations.

The Renaissance Center, HQ of General Motors and location of the conference hotel.

Detroit-style pizza at Buddy’s

Canada is one bridge away… to the South

The talk

I had given talks at smaller local meetups before, but this was my first time giving a “legit”, 30-minute talk in a conference. Preparing it consumed almost all my free time in the weeks beforehand, and I was pretty nervous beforehand.

Shout out to the RailsConf organizers for giving speakers all the tools we needed to have the best experience. They paired me with a mentor speaker to get feedback on it. I was matched with Noel Rappin and his feedback was very helpful as I was struggling to structure a longer talk. The speaker liaisons were also very present and helpful, and I never felt I was on my own.

Also, I draw what probably is the best slot for a speaker: the first talk of the first day! I could then attend the rest of the conference freely, and skip the stress. Whoever gave me that slot, thank you!

Picture of the audience during my talk

The last hurrah

On the very first day, Ruby Central announced that next year will be the last RailsConf. This came as a shock to many in the audience who either attended RailsConf regularly or, like me, watched the recordings every year. We realized that we were taking the conference for granted, and hearing the news was hard but made this one felt special.

Ruby Central hosted a Q&A panel for the community and shared their plans for the future. Organizing both RubyConf and RailsConf every year was eating up all their energy and bandwidth and they couldn’t focus on other things that mattered, like supporting the local ruby communities, fundraising, building ties with the Ruby Core team and improving Ruby documentation.

While I’m sad to see RailsConf disappear, I completely understand RubyCentral’s decision and agree with their long-term strategy for keeping the Ruby language and ecosystem healthy. It also made me think about all the work that goes on behind the scenes to keep basic infrastructure like rubygems.org running 24/7.

Talks and keynotes

All four keynotes were all amazing. We got:

• The inspiring story of the solo-founder behind The StoryGraph
• Many stories about Startups choosing Rails in 2024. As someone who wants to do more advocacy for Rails but doesn’t know how, this one hit hard.
• A look at a new ruby profiler, Vernier
• The classic tenderlove closing keynote, which starts with a stand-up comedy routine and ends deep in the ruby C internals. Honestly, by now I don’t know which one of the two parts is harder to pull off, but they’re both executed really well.

The talks I attended were also good, though I always get massive FOMO at multiple-track conferences. I’m looking forward to catching up on the ones I missed when the recordings are available.

#RubyFriends

It’s almost an overused sentence by now but it’s still very true. What makes ruby amazing is its community. Everyone I met was open, welcoming, kind and optimistic.

I especially liked seeing how much the community and the conference welcomed juniors and ruby beginners. There was a special program to provide free tickets and mentorships for juniors who applied, and pair them with more experienced developers.

I really feel this because when I reflect on what my best time was during the conference, it’s whenever I was interacting with the people. The hallway track, game night, speaker dinner and late-night-drinks were all highlights.

Hack day

One new experiment for this conference was a talk-free Hack Day, where attendees could participate in more hands-on activities:

• Coding on open-source projects with their maintainers
• 2-hour hands-on workshops
• A dedicated session for meeting book authors

My social and coding state of minds are not super compatible, so I did not code myself. But I enjoyed talking to maintainers of various open-source projects and telling them that their projects mattered and were useful to me, and I heard that people who coded really enjoyed it.

Hack day also allowed for some talk-free time to enjoy the hallway track or rest, which is more than welcome at a 3-day conference.

Optimism and gratefulness

As I’m coming off the conference high, I feel very grateful and thankful to RubyCentral for the amazing work they have been doing behind the scenes, keeping the community and infrastructure running all these years. Thank you.

I’m also more optimistic about the future of Ruby and Rails than ever. The community is strong, and the joy of writing ruby is still here. It’s up to us to spread it and be vocal about it. The future of ruby is bright, and the people amazing.

At the same time, I knew that totality would only last for about 3.5 minutes, and I sure didn’t want to spend all of it staring at my camera. So I decided to automate the process.

The challenge

When you only have three minutes to shoot an event, preparation is key. I wouldn’t have the time to fiddle with settings, everything should be set by the time totality comes.

A challenge when photographing an eclipse is that there is a large difference in the brightness between the lightest and darkest parts of the sun. The outer ring is very bright (you’re still looking at the sun, after all), but the corona extends pretty far and gets dim very quickly at the edges. In photography parlance, the scene is said to have high dynamic range.

Because of that, one shot is not enough to capture the full extent of the scene. So what I would need to do is you take multiple shots at different levels of luminosity to capture details in different aspects of the scene (a.k.a. braketing), then I could stitch them together in post-processing. Or just select one that I liked best.

Preparation

MrEclipse.com has an excellent guide to eclipse photography, which includes different camera settings to use when bracketing shots.

My lens had a fixed aperture of f/16, so at ISO 400, looking up the information in the table, I would need to have exposures from 1/4000 sec to 4sec.

The lookup table I used as a reference for the different shutter speeds when bracketing

Automation

I first tried different remote shooting apps but none of them was flexible enough to allow for this level of bracketing. Many of them were also unstable and and I didn’t want to take the risk of an app crashing on me or losing connection when my phone went to sleep.

This is when I decided to automate the process myself. After some research, I found gPhoto2 a long-standing library that can talk to cameras and control them remotely. I also found a ruby gem that provides ruby bindings to use it.

The next step was to create a ruby script to capture the different exposures needed for the bracketing. For safety and to cover for e.g. clouds, I made it so that every shot was taken four times, and ran the whole bracketing loop four times too.

The final script looked like this:

require 'gphoto2'

GPhoto2::Camera.first do |camera|
  speeds = %w[
    1/60
    1/4000
    1/2000
    1/500
    1/250
    1/15
    1/4
    1
    2
    4
  ]
  4.times do
    speeds.map do |speed|
      camera.update(iso: 400, shutterspeed: speed)
      4.times do
        puts "Taking exposure at #{speed}s"
        camera.capture
      rescue 
        nil # Cover for unexpected cases when e.g. the camera is busy
      end
    end
  end
end

Result

Once totality started, I ran ruby totality.rb, left the laptop and enjoyed the moment with my family.

I returned to it afterwards, and… everything had worked 🎉 Though many of the shots were black because of cloud coverage, I still got more than enough properly exposed shots to make up for it. And I didn’t need to be at the camera for any of it!

All the pictures taken by the script

Shot at 1/60s

Shot at 1/15s

Shot at 2sec, you can see the corona extend longer

This means that there are thousands upon thousands of image files gathering digital dust on a spinning cobalt disk inside my NAS. Each one of those pictures was shot at a moment where I thought it was important, passed the culling process then carefully processed in Lightroom. Realizing that all these pictures will probably never be looked at again made me sad, so I decided to do something about it.

The idea

Over the weekend, I had a thought: what if I could make my browser’s new tab page display a random picture from my stash? The image would change at regular intervals, keeping the novelty factor high and blowing some digital dust off the hard drive.

This had me think back to the old Webshots desktop setup I had growing up, that would change my desktop wallpaper every hour. It also incidentally turned me into a desktop image hoarder, but that’s a story for another time.

I rarely look at my desktop wallpaper these days, so I kept the idea but switched the canvas to be the browser new tab page, which gets opened dozens of times per day.

Prototype

The first step is to build a database of all the source pictures. A text file is enough:

$ find /Volumes/home/Pictures/Processed -type f -name '*.jpg' > all_pictures.txt
$ wc -l all_pictures.txt
    32588 all_pictures.txt

There are 32,588 pictures to chose from. To get one from the set, I can use shuf:

$ shuf -n 1 all_pictures.txt
/Volumes/home/Pictures/Processed/2013/décembre/NNC 2013/IMG_7683-3.jpg

All that’s left is to wrap this in a web server with some minimal styling, and voilà:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'sinatra'
  gem 'puma'
end

class App < Sinatra::Base
  get '/' do
    # Need to copy the image to the `public` folder because browsers
    # cannot load local files.
    `cp "$(shuf -n 1 all_pictures.txt)" public/chosen.jpg`
    
    "<img src='chosen.jpg' style='max-width: 90%; display: block; margin: auto;'/>"
  end

  run! if app_file == $0
end

I now had a page that displayed a random image, loaded on every refresh

Bells and whistles

Caching

Loading a different image on each reload is fun, but also very distracting and bandwidth-heavy. The solution was a simple in-memory cache to keep the same image loaded:

# cache.rb
class Cache
  def initialize
    @store = {}
  end

  def with_cache(key, &block)
    cache_hit = get(key)
    return cache_hit if cache_hit

    value = block.call
    set(key, value)
    value
  end

  private

  TTL_SECONDS = 5

  attr_reader :store

  def set(key, value)
    store[key] = { value: value, expires_at: Time.now.to_i + TTL_SECONDS }
  end

  def get(key)
    return if store[key].nil?
    return if Time.now.to_i >= store[key][:expires_at]

    store[key][:value]
  end
end

# server.rb
set :cache, Cache.new

get '/' do
  App.cache.with_cache(:image) do
    # ...
  end
end

Styling and metadata extraction

Using the exif gem, I could extract some EXIF metadata from the image file to provide more context about the image.

Add some extra styling and you have the final look of the page:

The final picture, with a full-width picture and metadata at the bottom

Setting the new tab page

This proved surprisingly harder that I expected, for a couple reasons:

• Firefox doesn’t support for custom urls for new tabs anymore, and recommends using browser extensions instead.
• When I tried some extensions, the behavior was odd: The new page opened, but it also focused the url and you’d have to manually clear the address bar before you can enter a new address. I lasted exactly 4 minutes before uninstalling them. There’s even a long-standing bug report about this.

After trying multiple extensions, I found one that managed to bypass this by embedding the desired page in an iframe.

This came with its own challenges, as browsers don’t allow pages to be embedded in arbitrary iframes anymore (nor should they). The solution is to set the CSP frame-ancestors directive on the server response to allow this:

response.headers['Content-Security-Policy'] = 'frame-ancestors *;'

This was the last piece of the puzzle, and I can now enjoy a new picture from my archive every hour.

Epilogue

A few hours in

In the beginning, the time between each new picture was set to 5 minutes. After a couple hours, I found myself compulsively reaching for my laptop to open a new tab and check the new picture. I accidentally hooked myself on a picture-induced dopamine rush!

When I realized that, I switched the timer from 5 minutes to 1 hour and that feeling disappeared.

A few days in

After a couple days using it, I have:

• Had many trips down memory lane.
• Sent some of the pictures to people I was with in the pictures, usually traveling.
• Looked up way too many people online to see what they were up to now.

I do have some ideas for future improvements, if I ever get to them:

• Also set the picture as a desktop background?
• Dockerizing the server so it can be run directly on the NAS instead of locally
• Saving the metadata along with the images to enable functionalities like “On this day”
• Adding a way to skip pictures that I don’t want to look at (I just restart the server when it happens)

As an inspiration, I chose a photography by Yusuf Karsh. He was a photographer who took portraits of statesmen and artists in the 40s to 80s. He has a series where he took pictures of hands, this one is Eleanor Roosevelt’s.

My version of it is me holding the fountain pen that I used during my university studies. French schools have a fascination for fountain pens, so I have memories of struggling to use one when I was in primary school.

Then this was one of the first items I bought when I landed in France, because I knew I would be using it a lot. Fountain pens adapt to your handwriting so you feel a special connection with them after using them for a while.

It’s also the pen that was with me during my formative years, when I left my teenage years to become a “real adult”, and I used that same pen to sign the paperwork that would take me to Texas then to Sweden.

It carries so much of my history that I felt like I was taking a portrait of myself even without having my face on the picture.

Personal development:

• Money is life energy. Vicki Robin - Your Money or Your Life
• Keep your identity small. Paul Graham
• Taming your inner mammoth. Wait but why
• Solitude can mean introspection, it can mean the concentration of focused work, and it can mean sustained reading. It can also mean friendship. Solitude and leadership

Work:

• Strong opinions, loosely held.
• It’s your professional obligation to push back on unreasonable expectations. Your bosses may not like it at first, but they will respect you for it. Source
• If you do the same thing as everyone else, you’re going to be average.
• Everything is a system. Think in systems.
• Heuristics Are OK: Heuristics (“mental shortcuts”) are have two sides you have to balance between:
  • a bad thing (base of cognitive biases)
  • a good thing (pattern matching, base of “gut feeling” in experts, aka tacit knowledge)

Time management:

• Saying yes to something means saying no to something else
• Doing something good but not essential is saying no to doing something essential
• If you’re doing the right things, it doesn’t matter how much time you spend on them. Podcast: How to Master Essentialism
• “Don’t be a donkey” aka Buridan’s ass. You can have everything, if you do one thing at a time.
• Other People’s Problems (OPP): Recognize them when they hit your inbox and ignore them.

Management:

• Culture is determined by which info you share and how decisions are made
• Delegate outcomes, not tasks:
  • SvN blog
  • Example in the military

Learning:

• Slow is smooth, and smooth is fast
• Get numb before you get good
• Balancing openness and skepticism

It seems to me what is called for is an exquisite balance between two conflicting needs: the most skeptical scrutiny of all hypotheses that are served up to us and at the same time a great openness to new ideas. Obviously those two modes of thought are in some tension. But if you are able to exercise only one of these modes, which ever one it is, you’re in deep trouble. If you are only skeptical, then no new ideas make it through to you. You never learn anything new. You become a crotchety old person convinced that nonsense is ruling the world. (There is, of course, much data to support you.) But every now and then, maybe once in a hundred cases, a new idea turns out to be on the mark, valid and wonderful. If you are too much in the habit of being skeptical about everything, you are going to miss or resent it, and either way you will be standing in the way of understanding and progress. On the other hand, if you are open to the point of gullibility and have not an ounce of skeptical sense in you, then you cannot distinguish the useful ideas from the worthless ones. If all ideas have equal validity then you are lost, because then, it seems to me, no ideas have any validity at all.

• Consume books and art that stood the test of time.
• Thinking from first principles.

Arguing:

• When arguing, always consider the best version of the opposing argument (steel man argument):

The most powerful way to avoid using bad arguments and to discourage their use by others is to follow the principle of charity and to argue against the strongest and most persuasive version of their grounds.

source

Creative work:

• Ira Glass’ taste gap
• Writing FBR (Fast, Bad and Rong)

People:

• People like us, do things like this
• The banality of evil

Note: Gnawa music
Probably the most exported style of Moroccan music, Gnawa is a genre with religious roots and is still played in spiritual ceremonies today.

After the 90s, Gnawa music has been modernized and it is now played outside of religious ceremonies. Many musicians, both local and foreign, experimented with mixing Gnawa rythms with other styles. The first three entries of this list are examples of this.

1. Majid Bekkas & Louis Sclavis, Minino Garay - Boulila
Gnawa + Jazz trio

Musician Majid Bekkas combines blues, jazz and gnawa music.

2. Jimmy Page, Robert Plant - Wah Wah
Gnawa + Rock

14 years after Led Zeppelin‘s dissolution, former members Jimmy Page and Robert Plant recorded the live album “No Quarter”. The album was partly recorded in Morocco with a Gnawa band. “Wah Wah” is one of the songs they recorded together. You can listen to it here.

3. Snarky Puppy & Hamid El Kasri - Lalla Aicha + Lingus
Gnawa + Jazz ensemble

During the the 2018 Essaouira Gnawa festival, award-winning jazz collective Snarky Puppy collaborated with a prominent Gnawa band for a unique concert. The set’s finale is a crossover of popular Snarky Puppy song Lingus with a staple of Gnawa music, Lalla Aicha.

4. Aza - Tifiras
Tamazight music + Jazz

AZA unites traditional Tamazight (Berber) music, indigenous to the Atlas Mountains of Morocco, with the jazz and soul influences of its diverse members. Although they are now US-based, the founding members originally come from the small town of Imintanoute, my father’s hometown.

5. Oum - Lágrimas negras
Moroccan soul + Cuban trova

Lágrimas negras is a popular Cuban song first recorded in the 1930s. Moroccan singer Oum covers this song, and translates parts of it to Darija, the moroccan dialect of Arabic. This is one of my favorite pieces, and combines elements from Morocco, Cuba and France.

6. Abdessadeq Cheqara - Bent Bladi
Andalusi music + Flamenco

Andalusi music is more than a thousand years old, and is in its traditional form a very formal genre, akin to classical music. Abdessadeq Cheqara, during a trip to Spain in 1982, collaborated to produce a combination of andalusi music and flamenco, with intertwining Arabic and Spanish lyrics. This has become one of his most popular songs and a tune most Moroccans instantly recognize.

7. Hindi zahra - Imik Si Mik
Tamazight music + Folk

Hindi Zahra is one of the first artists to mix tamazight music and Western-inspired folk, and sings in both berber and english in the same song.

I justified the expense by the fact that the praise for that piece of hardware is almost universal, and even our beloved thought leaders™️ seem to be in on it.

I swear by it now, but damn, that thing is loud.

Where does the noise come from?

As with all mechanical keyboards, there are two main sources for the noise:

• The case, which acts as an echo chamber amplifying the vibrations from the keys. This is particularly bad on the Advantage, with its large hollow space between the keywells.
• The MX switches themselves, especially if you’re bottoming out when typing.

To get rid of the noise, both of these problems have to be addressed.

1. Dampening the case

The best way to reduce the vibrations from the case is to line it with dampening foam. The dampening material will absorb the vibrations instead of letting them bounce around until they hit your ears.

There are various options here: Dynamat, Sorbothane, Neoprene or plain old packing foam. The trade-offs are cost and weight: the heavier the lining is, the stronger the dampening — more weight equals more vibrations absorbed. But these materials can get expensive pretty quickly.

I lucked out and found some cheap Dynamat Xtreme on a small local auto parts website, and installed it inside the case:

The Kinesis Advantage with the Dynamat Xtreme.

The inside of the case, with the PCB exposed.

The case, lined with Dynamat Xtreme.

2. The switches

A classic drawback of mechanical keyboards is that the switches themselves are loud. Fortunately, this is an almost-solved problem, with solutions like the Uniqey QMX clips made to solve exactly this problem. So we can just throw money at it.

The clips come in two flavors: plate mounted and PCB mounted. The Kinesis Advantage needs both variants: the thumb cluster switches are mounted directly on the PCB, whereas the keywell ones are mounted on a plate.

Keycaps removed.

All keycaps in place. Note the colors: white keycaps are plate-mounted, transparent are PCB-mounted.

Result

After putting everything back together, the keyboard is much more silent. It’s also significantly heavier — and expensive 😬.

Here’s a before/after audio sample. Unfortunately the levels between recordings aren’t normalized, so the “after” doesn’t sound much quieter :( It’s definitely the case in real life though! If you pay attention, you can notice that the sound got less “clicky” after the modifications.

Overall I’m really happy with the result and it made for a good weekend project!

Notes:

I considered other alternatives to further silence the keyboard, but ultimately decided against them because I was happy enough with the result:

• Getting PBT keycaps, which are heavier and produce a slightly quieter (and deeper) sound.
• Getting the Advantage with the quiet LF switches rather than the Cherry MX brown switches. This model was not available when I ordered mine, and I didn’t want to wait for it to arrive, for the sake of my fingers.

Links:

• The main inspiration for this project was this comment on reddit.
• A good overview of noise sources in mechanical keyboards and how to counter them.

Production software should empower users to do things that were once painful or impossible. There are far too many paper cuts in the software around us today, and I want the product I work on to be a well-deserved break from them.

Software that doesn’t make people’s life easier isn’t worth writing.

Start with why

Whenever working on a feature, I want to understand why it is needed, what value it is providing, to whom, etc…

This helps me get to the core issue I am trying to solve, guide my work and understand which tradoffs are possible to make. If you work with me, “why are we doing this?” will be by far the question you will hear the most.

I take pride in my work

Any piece of code I write reflects on me and my ability to write good, maintainable code.

I strive to be nice to myself and my fellow colleagues by writing code that’s clear, well-designed, readable and even boring.

Code is a liability

I think of every line of code written as a liability to the team that will have to understand and maintain it.

As a software engineer, my goal is to provide business value, not to write code. If I can provide the same value without writing code, I will try to do so.

The value of good-enough

A good-enough solution today is more valuable than a perfect solution tomorrow.

I believe in shipping early, scoped down, solutions that can be used as a basis for iteration. Then iterating just enough to provide the business value that makes sense for the current need and scope.

Shipping is a goldilocks game, and the product should be neither rough on the edges nor an overengineered page that will delight its users on every click when it’s shipped, one year from now.

There is no right or wrong, only tradeoffs

In software and in life, the answer to many questions is “it depends”. Every choice made involves tradeoffs, wether explicit or implicit.

I strive to always be aware of this, and ask which tradeoffs will help my case and my users best in any given situation.

Some strong opinions, strongly held

I try to be not opinionated about too many things, and keep my identity small.

In the areas where I do have opinions, I believe in them enough to act on them with confidence and argue my stance strongly.

‘tis Christmas season, time for snow, carols and joy,
The code freeze is here, yesterday was my last deploy.
Still my favorite moment is when under the tree,
I always find a new version of ruby.

Today I take this opportunity to reflect on the past
Where my journey began, not knowing how long it would last.
_why’s poignant guide was an amusing read
It made me smile and think: “wow, this language is weird!”

Writing programs soon felt simple, elegant and natural.
No convoluted syntax here. Trust me, I looked.
It was the best of perl, lisp and smalltalk,
And none of the quirks. That’s it, I was hooked!

And then there was this thing called Rails,
A blog in ten minutes, could this be possible?
It was a lot to take in, but I hung in there
The tutorial helped a lot, thank you Michael Hartl!

Years have passed, and Rails is now my daily craft
I still enjoy every moment of it. Yes, even ActiveRecord.
And when people ask me “is ruby dead?”, I just answer:
No. It’s just boring, in the best sense of the word.

Don’t get me wrong, I love innovation and new ideas
But it sometimes seems like the web has jumped the shark
So I’m happy to get off the new framework treadmill
No web3 for me, thanks. I’m off to the park!

For I don’t want shiny. I want productive and simple.
What I need is to write code, and maybe be weird once or twice.
Join us under our big tent, you are more than welcome
For Matz is nice and so we are nice.

So here’s to you, Ruby, Rails and the whole community,
May you still thrive and make people cheery.
I leave you now, and go back to my desk
For I once again have trouble installing Nokogiri.

Edit: Hello hacker news! 👋 You can find the discussion here

So you have just accepted your first job offer in tech. Maybe you even updated your Linkedin profile to say “Junior web developer”.

First of all, congratulations for making it to this point! Whether this is your first job or you have transitioned from another career, I know that looking for that first job is not easy.

Welcome to the web development industry. We’re a young field, and we’re collectively still figuring some things out, as you are. For example, you might have noticed that we tend to suck at hiring processes.

There is one thing we know for sure: we need you. We need way, way more members in our community than we currently have, and almost all teams I talk to are understaffed. This is a great time to join us.

This is the beginning of a long journey for you. “Web development” is a broad topic, and there is enough material for a lifetime. I mean, look at this:

Image from the Hack Reactor (formerly MarkerSquare) 6-week bootcamp

If you think this is overwhelming, I completely agree. But the key thing is that you don’t need to know all of this to be a good developer. Not only that, it’s actually rare to find someone who’s fluent in all these aspects. From now on, you will slowly pick up some branches of that tree, expanding your knowledge bit by bit, day by day.

The journey you embarked on is one of learning. Faced with this, I imagine your next questions are: how do you even take on something so huge? What to learn? How? Where to start? When to stop?

This is what I am going to cover in the rest of this letter. This is the advice I wish I had when I started my own carrer.

1. What to learn?

Basic fluency in the core technologies of your stack

As with everything, we start with the basics: understand what technologies you are going to be using in your daily work, and become fluent in them. This means understanding the syntax of most of the code you’re reading and have a general idea of how different parts of the system fit together.

A common mistake I see is new developers learning new programming languages or frameworks before spending meaningful time with the one they started with. Stick to one and become proficient in it. This will make you build the foundational knowledge you need to progress.

The fundamentals

Fundamentals are the basic concepts that are used all over the place, regardless of technology. They are valuable to learn because:

• They don’t depend on any specific technology, programming language or framework. This means that you only need to learn them once, then that knowledge can be reused for other jobs, projects and teams.
• New concepts “click” easier when you can see the big picture. The more you know, the easier it is to learn new things.

Examples of fundamental concepts:

• The HTTP request/response cycle
• The server/client architecture. What is a web server, a client?
• The DOM and its interaction with the browser API
• HTML/CSS
• Git

Thoughbot has a good list covering these, what they call “evergreen skills”.

This is often a place I suggest beginners to focus on as they are often skipped by education programs: fresh graduates tend to have a more computer sciency background, whereas many bootcamps focus on teaching you the tools that you need on your CV to get a job, but skip the fundamentals.

Learn your Tools

By tools, I mean anything that use to do the job, but are not part of the job assignment per se. You are going to spend a lot of time using your tools, so invest some time in learning them so you can be fluent using them.

Some examples are:

• Possibly a new operating system (if you’re transitioning from Windows to Mac for example).
• Your text editor. Text editors are packed full of features that are sometimes not very discoverable. You will spend most of your time in them, reading and writing code. Being comfortable in your editor will help you in many, many ways, so it’s worth it to spend some time building up your skills there.
• The terminal/shell. This is a daunting one for beginners, again because of the poor discoverability. However, you only need to know the basics to get you started, you pick up the rest as you go. I recommend the learn enough book series as a starting point.
• Git: this is also one that has scarred many beginners, and the mere mention of a big merge conflict will make any developer’s heart sink a little. It’s one of these tools that is more complex than they need to be, but there are some ways to make your work easier:
  • learn the basic concepts, they’re enough to get you out of many situations. Here too, I recommend the Learn Enough book.
  • You could use a GUI program like Tower, Fork or GitKraken to help you visualize what’s happening.
• Debugging tools in your language of choice: learn how to inspect variables, stop the code at any point, look around. Debugging is a whole skillset that is often overlooked, but it can help a lot when things don’t work the way you think they should.
• Internal tools for the company, e.g. project management like Jira or Github.

Learn to communicate

Learning how to communicate with your team and peers is one of the most useful skills you can learn, as it will have ripple effects on everything else.

Learn to express what you don’t know. Learn to ask questions in a way that make them easy to answer. Try to explain things to yourself so you can clarify what you don’t know.

This becomes even more important when working remotely, because communication isn’t instantaneous. One well formulated question can avoid some frustrating back and forth, so be generous on details. When in doubt, lean towards overcommunicating. What’s obvious to you might not be to anothers.

2. Your learning tools: how to learn?

Learn to learn

Learning is itself a skill — talk about meta! This is another one of those areas that has ripple effects throughout everything you do. Learning to learn is too broad a subject to fully cover here, but here are some pointers I found useful:

• Mix structured and unstructured learning, by alternating guided tutorials and small independent projects.
• Find your style of learning:
  • Do you prefer to learn the fundamentals of a subject and build up from there (“bottom up”)? Or are you more likely to learn by doing and practice (“top-down”).
  • Do you prefer learning from written material (blog posts, books) or from video courses?

This is of course highly personal. Be mindful about how you learn most effectively and seek learning material that fits your style.

Get help

If you’re in a good team, they will guide you through your learning journey. Don’t be afraid to ask questions and seek feedback from them.

On top of that, find a mentor if you can. Maybe several. They will be someone who you can turn to when you have questions and will have the bandwidth and patience to help you. Having this relationship with someone makes it less scary to “ask stupid questions” (which you should absolutely do!). It’s important to find someone who you click with, and whose style of teaching you like. The same way different people learn in different styles, not all mentors fit everyone.

A couple reasons why mentors help in ways that are hard to replace:

• There is a lot of content on the web of dubious quality. It’s hard for a newcomer to distinguish the good from the bad when reading blog posts and StackOverflow answers.
• They help you see the big picture when you’re stuck on a detail. This way, you not only get an answer to your immediate question, but you also get to know why things are a certain way.

Keep a learning diary

Recording notes, ideas and questions is a practice that can be find in many disciplines, for example engineering notebooks or sketchbooks for artists.

A learning diary is a key tool in your learning process. It’s what you use to offload your brain and keep track of:

• What you have learned today.
• Questions or foreign concepts you have at the moment that you want to look up or ask someone about later.

It helps you not get overwhelmed by all the things you don’t know yet and keep track of your progress. Looking back on last month’s entries and seeing how much you have evolved feels very rewarding, even though you may feel you haven’t progressed much.

The diary itself can be either a physical notebook or digital notes, up to you! The important thing is that you keep one.

How to pick learning resources

There is no shortage of learning resources on the web today, but that doesn’t mean they’re all equal in quality. Here are a couple rules of thumb when it comes to choosing your learning resources:

• Aim for complete books or courses rather than short blog posts or videos if you want to have a solid understanding of a concept. Blog posts or short videos are fine if you need to quickly look up a specific aspect or feature of a library or tool, but lack the in-depth elements that make for a complete understanding. To make things worse, some companies have a tendency to post low quality technical blog posts for SEO and visibility purposes, which can harm your understanding.
• Ask around for good learning resources in your specific domain. I recommend Frontend Masters for anything frontend and Upcase for ruby on rails.
• Learn to read technical documentation. You will have to read a lot of technical documentation as you work, and it can be hard to figure out what the relevant parts are.

Other resources that newcomers tend to underestimate are podcasts and recording of conference talks. Here you don’t usually chose the exact subject, but instead trust the speaker or podcast hosts to do it for you. This can be very helpful for broadening your horizons to ideas you were not aware of, but it’s also what makes these very hit or miss: listen to a talk without having the necessary background knowledge and you’re not going to take away much from it.

So if you’re going this way, ask around you for podcasts or talks that fit your current level.

A note on tutorials: Tutorials are a good resource to first get started with a new tool or technology, but it’s very easy to abuse them. You can end up writing the same app over and over again, without really gaining more value or understanding from the process (a.k.a. tutorial hell).

3. Programming and you

Unlearning bad habits

On your journey here you might have picked up some bad habits. You’ll need to unlearn them, as they will make life harder for you and can slow down your learning. Some common ones are:

• Treating code as “magic incantations” and copy pasting code or commands you don’t understand. This is necessary in the beginning when you don’t have enough background to understand everything that’s happening. But after a certain point, you should grow weary of these and seek to understand the concepts behind everything you see or type.
• Making technical decisions because of what other people or organizations have done, without understanding why. Figure out why and how technical decisions are made, and what trade-offs are involved. Knowing the fundamentals helps tremendously here.

Impostor syndrome and you

This is not an easy profession to get into, and the amount of knowledge needed to tackle some apparently trivial issues is sometimes staggering and intimidating to a newcomer.

This might make you wonder if you’re smart enough for this job, and why you are the only one that doesn’t seem to “get it”. This especially applies if you come from a non-traditional background, such as a bootcamp after a career switch.

Impostor syndrome is real, and it’s not just you. Many people —including me— have dealt with this at some point in our lives, along with other not-so-nice emotions. Don’t let that discourage you. It’s okay to not know everything, that’s why you are a junior after all.

Don’t compare yourself to people who have been doing this for a long time, they have had the time and space to practice and digest the knowledge bit by bit. You should, however, compare yourself to yesterday you, and make sure you’re continuously learning new things. This is the only comparison that matters or makes sense.

Note on the complexity of the web today: At times you might feel that things are too complex, especially if you’re working in the javascript ecosystem. It’s not just you. This has been an ongoing gripe of web developers for years: our tools have become way too convoluted. Some communities are fighting back, but this is a story for another post.

Find the fun in programming

Depending on your background, you may or may not have programmed purely for fun. Having an idea in your head and making it come to life is a wonderful thing, and can be the source of a lot of creativity and joy.

Unfortunately this gets lost in the complexity of the tools and the pressure to code for a career. It’s hard to see the fun when your day job is making small changes in a large codebase where everything takes way longer than it should.

There’s nothing wrong with doing this purely for the money, but it’s missing out on the best part.

So, once in a while, try to make your own little thing, for you or someone you care about. Maybe make them an online picture gallery for their birthday. Or write a facebook chat bot filled with your in-jokes. An app doesn’t have to be used by millions to be successful, it can be a home cooked meal for a selected few who will appreciate it and bring you joy.

The possibilities are endless, and this what attracted many of us in the first place. I hope you get to experience this too.

Again, welcome to our industry and community, and I wish you a wonderful career!

Youssef