Skip to content

Skills

About The Following Skill Set Presentation¶

The following skill set is as exhaustive as possible. The level scale is inspired by the CEFR (Common European Framework of Reference for Languages) to offer the most descriptive and simplest way of evaluating each skill.

There is the adapted nomenclature:

Icon Level Description
Beginner Barely able to use it for the simplest features.
Elementary Understand basics, philosophy and can do simple things easily.
Intermediate Sufficient understanding for smooth regular daily work starts to be productive.
Upper intermediate Start using the most advanced features, medium productivity.
Advanced Advanced usage, strong experience good productivity.
Expert Almost full mastery and deep experience, full productivity.

Important

As you read this, keep in mind that learning fast is part of my daily job.

I have a very strong understanding of the web ecosystem as a whole, from networking to web technologies. I know what's behind main frameworks in web stacks, what problem they do solve (and those they don't), as such I can be operational in a matter of days(1) on a new framework or technology I don't yet know.

Being operational meaning reaching the Elementary level, and such being able to understand the tool and the code, the philosophy behind it and, of course, to work with it.

  1. If a good documentation can be provided. Without any documentation, the delay would either be a week or more depending on the degree of rigor employed while developing said tool.

Meta¶

This section regroups skills and knowledge indicators that are related to my daily work and/or past missions/businesses. They are not IT specific.

Business & Management Skills¶

  • Motivation1
  • Problem-solving and decision-making
  • Communication
  • Budget Management2
  • Organization
  • Strategic ressources allocation3
  • Planning & estimation4

Soft Skills¶

  • Team working


    Being able to work together with the same goal in mind and a strong cohesion sense is crucial to succeed as a developer. But it's even more important when it comes to building something.

    I'm naturally open to others, friendly and eager to share whether it be about the projects I'm working on or just every IT-related (or not) subjects.

  • Adaptability


    My missions in the past few years were very different, with many companies, tools, people or even workflow that adaptation became a second nature.

    Not only am I adapting to your project, team and processes, but I'll do my best for my code to be as close as possible as the codebase I'm working on. Codebase homogeneity is one of the most important things to maintain across a project's lifecycle.

  • Creativity


    Creativity is such a fascinating thing. Some people refer to it as a gift. I strongly disagree. I rather see creativity as a muscle: the more we invest time and effort to create new things, the most creative we become.

    Being creative is an active process. We're not creating many things because we're creative. We're creative because we're trying to create as many things as possible, as often as possible.

  • Resourcefulness & curiosity


    My work isn't about knowing or memorizing everything, but rather knowing where to search for, keeping my knowledge up to date and reading/listening/watching as much as possible about as different non-related subjects as possible.

    This way, I can dig and thorough a subject later, when I think that it may be useful for my current task, mission or project.

  • Critical thinking


    Most of my side project's purpose is exactly this. Before even trying a new framework/library, I try to ask myself: How would I solve the problems it solves?

    Implementing a proof of concept before using a library/a framework feature is something I do a lot. It not only help me improve my skills overtime, but it helps me spot my solutions strengths and weaknesses.

  • Openness to criticism


    Writing code is not just about applying technical knowledge. It's about solving problems in a creative way. The creative way part is such a subjective thing that not being able to keep a certain distance with our code may poison our developer career.

    I don't see criticism has something against me, but as something that is helping me being better at what I do. As such, substantiate critics are always welcome.


Technical Skills¶

Concepts¶

  • OOP
  • SOLID principle
  • Relational Model
  • DDD
  • TDD
  • CQRS
  • Event Sourcing
  • Functional programming

Languages¶

  • JavaScript (ECMAScript 2022)
  • CSS 3
  • HTML 5
  • PHP (> 5.5)
  • SQL
  • Bash / shell scripting
  • TypeScript5
  • Java

JavaScript Runtimes¶

  • Nodejs
  • Electron

Web Technologies¶

  • AJAX/Fetch API
  • Websocket (client, server, protocol)
  • HTTP/HTTPS (server, protocol)
  • CSP
  • Service Worker / PWA
  • Web Worker
  • WebComponents
  • WebRTC (client, STUN/TURN, MCU)
  • Push notifications

System Administration¶

  • Linux (mainly ubuntu desktop & server)
  • VPS setup
  • DNS setup
  • Mail server setup

As a Web Agency founder, I set up the whole infrastructure including a dedicated server for a multi-site (created with a homemade framework), and a fully fledged multi-domain mail server, with web mail client, multi-domain web mail admin with quotas, spam & virus filtering, etc.

Tools¶

  • PHPStorm
  • SublimeText
  • Git
  • GitHub
  • MySQL Workbench
  • MKDocs Material
  • GitHub Actions6
  • Visual Studio
  • Eclipse

Databases¶

  • MySQL
  • MongoDB
  • Elasticsearch
  • Redis

Frameworks / CMS¶

  • React.js
  • Magento2
  • Wordpress
  • Angular
  • Vue.js

Not that spectacular, huh?

My everyday work being for a long time to work on from-scratch projects without known frameworks, I must admit that it's not this page's most impressive section 😅.

But it doesn't mean I'm unable to work with them in no time. I had to slightly deal with them over the years, and my ability to enter and work on non-standard projects would allow me to work with those frameworks/CMSs without requiring too much effort, especially since they benefit from a tremendous amount of online resources and very well written and thorough documentation.

Cloud services¶

  • AWS
  • AWS S3
  • Azure AD
  • OneDrive API
  • Google Auth
  • Google Drive API
  • Box API
  • DropBox API
  • LinkedIn Auth
  • Facebook Auth

Note

Most usages are integration into websites/applications, mostly on NodeJS for login and/or file upload/retrieval.

The only real cloud configuration done on AWS for my part is an AWS Nano deployment to deliver a spectre instance at spectre.jordan-breton.com for my own usage.

More generally, working with any cloud/service providers either with their UI and/or through their APIs is not that hard and only requires to be able to read their documentation most of the time.

That being said, being a Cloud Engineer is not trivial at all, especially when it comes to working with the most famous providers. I would love to experiment with them in the near future.

The thing is... days are only 32 hours long, aren't they?


Non-IT Skills¶

  • French novel writing
  • French poetry writing
  • Sketching
  • Digital painting

Tools¶

  • Photoshop
  • Illustrator
  • Microsoft Office suite
  • Ardour
  • After Effects

Languages¶

Language Written comprehension Written expression Oral comprehension Oral expression
French (native)
English 7

  1. Working hard to run my own businesses early in my career while being alone for very long years was really challenging. But my motivation to stay the course and move forward never wavers, especially in the most difficult moments. ↩

  2. As a business owner myself for quite a time, budget management was obviously a mandatory skill to learn. ↩

  3. As a lonely developer with very few resources and a small-to-inexistent network when I started my IT-Journey, I had to deal with incredibly very limited time, money and skills. Dealing with these kinds of restrictions strengthened my abilities to prioritize and delay where needed. ↩

  4. My time estimates improved greatly over the years but let's be honest, there is still room for improvement 😄. No matter how much I try to stop underestimate the time needed to do something, my optimistic nature just keep staying in the way. This is one of those domains where time and practice are the only way to mastery. ↩

  5. I worked only on a few projects with TypeScript. Since I'm an expert at JavaScript and OOP, mastering TypeScript is only a matter of syntax and practice. ↩

  6. I already set up several GitHub actions for automatic and manual (one click) deployments from GitHub interface on a company VPS I configured, including emergency switches in case of outage one the main production server. ↩

  7. Mainly missing some practice. ↩