I know that I don’t know lots of things.
But I know that I love learning by myself and learning from others. I love teaching to others. I love making great stuff. I love open-source. I love understanding the business.
I used to work on Hadoop clusters, dealing with the Data flow (Flume, Kafka), writing some Spark, and handling the analytics part. I’m quite a fan of the Google Cloud Platform for everything now. From their databases, GCE for Virtual Machines, GKE for Kubernetes, or GAE, it can really answer to any needs nowadays.
I’m fluent in Scala, and most of its ecosystem, still trying to wrap my mind around the humongous Category Theory. I still need to learn Haskell, and probably Eta to push the Functional Programming paradigm to its climax. But I’m also eager to learn Go and Rust for instance. We should never get stuck into one language, and get the vision of the other languages.
↓ Below is how I think a company should work and where I like to work. ↓
If your company, teams, and projects fit all this, then we can probably work together! :sunglasses:
Send me a tweet or use this form (private, no worries). French or English.
Members of a team have to be passionated about their job. We are in a position where we can love what we do, not just do it to pay the rent. We should understand our business, be able to talk with the shareholders, understand the strategies, be part of the whole.
A team should work with the vision of the company always in mind: it’s easier to take decisions. Do they follow the vision, or not? What matters is the company: no decision should be personal. We are all working for the sake of its wellness.
Everyone is a user for some other companies. Why not offer them the same they offer us?
We want our website and applications to be fast, reactive, and consistent. We should not sacrifice all of it for the sake of time and budget. The impact must be measured. The UI/UX should be designed by the dedicated roles, not by the developers. We should monitor our systems, to always be aware of what’s going on. We should not wait for the user to explain us our add to cart feature doesn’t work anymore.
Code is an art. Yes, that’s Software Craftmanship talking here. We should not be satisfied with something that just works, but that will be unmaintenable for the next person to work on it. Code has to be tested and shared through code reviews and pair programming. Code should be about business à la DDD, and technical concepts properly separated. We should also prioritize the Functional Programming concepts: immutability, purity, no side-effects, among other things; to make the code a better place (easier to reason about). Knowledge is about code and business: it has to be learned and teached.
Bugs are not a problem. We are humans. But the same bug should never happen twice. Post-mortems and tests are here to help us. We should build a virtuous circle of tests and deployments. We want feedback fast.
Data are first-class citizens. They are ubiquitous.
It should be understand by every employees. Companies produce tons of it. It’s always possible to do something with it, get insights, and improve upon them. We just need to know where to look, how to extract them, how to process them, how to store them. Data Scientists can understand the data (provided by the Data Engineers) using Machine Learning.
A flow of events can scale to hundreds or even thousands requests per seconds! The cloud is a real opportunity to scale easily and have a proper control over resources, budgets, and permissions.
Distributed systems are complex and present tons of subtilities and knobs to be aware of. We don’t want to lose data. We don’t want to expose our users to inconsistencies that would refrain their purchase.