Right now, this means that I'm coaching 20 candidates-entrepreneurs at LeWagon bootcamp, Brussels session. The train has departed already, but we are opening more sessions this year, so don't hesitate to sign up or contact me for more details. If you have a startup idea but lack the technical skills to code it, join us!

At the same time, I'm still coaching a development team at Swift, both on the technical side and on the delivery side.

Working in both Startups & corporate environments has given me some perspective on both worlds. I love to hear about startups ideas - what's yours?

If you are interested in my experience, don't hesitate to get in touch.

My decision process evaluation (only) rule

I've worked in many environment, from PullReview's two-man structure to very large companies. I've seen a lot of teams with a lot of different ways to reach decisions. I don't think there is a good one, but I do think there is some bad ones. Whatever way you pick, it should respect a single and simple rule:

Your process should allow you to reach a decision in a specific amount of time.

The "amount of time" being dependant on the decision to take - some things are of much more importance than others, but should be fixed in advance as much as possible:

• "So, we have two options for our Continuous Integration, let's take 30 minutes together to discuss the pros & cons and pick one"
• "We need to have our next release content fixed before Monday"

Some process that succeed...

Some process that do follow that rule:

Dictatorship

A Dictatorship happens when a specific person take the decision at the end of the allocated time. The reason can be hierarchical, but that's just one among a lot of others.

Altough the word is somewhat pejorative, I've no qualm with Dictatorship, especially if it is linked to some kind of skill. As an example, if we do have to take a decision regarding the servers with the team, I'll tend to let the sysadmin take the decision. I'll contribute to the discussion and expect to be listened to, but I'll bow to the person with the most knowledge.

Another Dictatorship option is to let the person that is doing the discussed task (or that will do it) decide.

This means that the Dictator can be various persons, depending of the context. What matters is that the context (and so the Dictator) is clear to everyone.

Democracy

A Democracy is when at the end of the allocated time, the stakeholders vote. The decision with the highest number of vote get implemented.

I did not see the Democracy implemented a lot, except in Scrum processes' retrospectives, but it is following my unique rule. The caveats are that the "diktat of the majority" may lead to strange situations.

I remember discussing the way the knowledge was shared between developers inside the team. At the end, there was two opinions: use a "everyone pick the first story on the pile" approach versus a "each developer nominate and train a specific backup for his/her projects". The second option was the leader in the votes, even if no developer in the team actually voted for it - we were outvoted by non-coding team members on a subject specific to coding.

Throwing a dice

Probably a far fetched example, but throwing a dice is a valid decision strategy regarding the unique rule. Probably a bad one, but probably better than the options below.

...and some that do not

Consensus

A Consensus require all the stakeholders to agree for the decision to be taken. In practice, it means giving everry person a veto, so that no decision will be taken until everyone agree - which requires a non-predictive amount of time that increase very quickly with the number of persons involved.

Delay/Delegate

A Delay happens when at the end of the allocated time, the decision is delayed to another date (often to another meeting actually). A Delegate happens when the decision power is transferred to another person at the end of the allocated time.

None of those can garantee a decision in a specific amount of time, so they should be avoided at all costs. Despite this, they are actually pretty common.

We have rules for the cases that don't work

Something I heard a lot is: "you should first try to agree together before coming to this sort of process". Fact is, I do. You don't need rules for the cases that work. You need them for the cases that don't. If you agree from the start, then you don't need a process on that case, and that's good.

Conclusion

As one our our advisors said to us at PullReview:

"Your problem is that you still think there is good and bad decisions, while there is just the decisions you take and those you don't."

This means that your company/team has to take decisions. If you want those to be taken (and you should!), be sure to

• allocate a specific amount of time to each (5 minutes is a perfectly reasonable time to take most decision)
• timebox the interventions if needed (ie, don't let someone talk for 15 minutes if you have 5 persons in the room and 30 minutes to decide)
• be transparent about the rule used to take the decision
• try to limit the number of people involved

They try to eat the whole problem in one bite

Like hungry little kids, when facing a programming problem, they try to figure out a full solution, in their head and/or in their code. And like little kids, the result is a lot of splashed food around, and not that much in the mouth.

This make little kids (and little programmers) angry, which means that the next bite become more and more complicated, until they give up in frustration.

An example

One of the exercises from LeWagon Bootcamp was to translate a text (several words/sentences) into "louchebem" - a slang used notably by parisian butchers a while ago. To "louchebemize" a word, you apply the following rules:

• Move the first syllable to the end if it starts with a consonant
• Add a "l" as first letter
• Add a "ji" suffix at the end
• One-letter words are kept "as is"
• Punctuation or other special characters (dots, quotes, commas, apostrophes...) needs to be kept "as is"

Our placeholder was something like:

def louchebemize(text)
end

Our test harness required the ´louchebemize´ method to return the text in its new form.

As an example:

louchebemize("Bonjour à tout le monde!")
=> "Ljourbonji à ltoutji lleji ldemonji!"

What the students did

Starting on something that was a rather complex program (several rules/steps), most of the students attempted to implement the full transformation in one cut, resulting in a code with several errors.

The testing period was then quite painful, as multiple problems occured - from syntax to logic ones, making the debugging both complicated and frustrating.

This was made even worse as the program itself was not running at all (due to invalid syntax).

The problem

The main problem of this approach is that they were trying to figure the whole problem in their heads - and logically couldn't.

This leads to writing block and frustration - from a solution that they (rightfully) thought 80% right. Unfortunately, in programming, the devil is mostly in those 20%.

A better way

Seeing this scenario happens again and again forced me to get back to the way I did create my own solution, and to see how to push them in the right direction (without simply helping on the debugging) -- the interesting part in coaching is that the objective is not really to make the code run, but mostly to be sure that the next problem will be tackled better.

I asked one student the logic he wanted to use, and he told me directly:

• I'll iterate on each word, then...
• Why don't you do that already? Just the loop.

Looping

Quite logically, I was called again by the same student. His code looked like:

def louchebemize(text)
  text.split(" ").each do |word|
    # ???
  end
end

• I've done it, but this is of course not working.
• Why don't you return the sentence already?
• It won't help - I did not do any transformation yet.
• Do it anyway.

A few minutes later:

def louchebemize(text)
  louchebem_words = text.split(" ").map do |word|
    word
  end

  louchebem_words.join(" ")
end

This was I call the 10%: the program is doing something, and most importantly, it is running (outputting the text 'as is'). Should there be any mistakes in the loop, split or join logic, it would be easy to catch & fix - it is just 3 lines of code.

Funny part, the student initially was not really happy with this - it did not look to him that he had made any progress toward a solution. Yet.

• Looks good. Now you can start with the rules. For example, you could already add the suffix 'ji' to each word.
• Except the ones with only one letter?
• Disregard that for now - we'll add it after.

A few more minutes later:

def louchebemize(text)
  louchebem_words = text.split(" ").map do |word|
    word + "ji"
  end

  louchebem_words.join(" ")
end

Again, this code is clearly not getting the right result, but:

1. It runs
2. It is one step further towards the solution

Several errors where actually found & fixed directly at that time by several students (like using an 'each' instead of a 'map').

We had to repeat this several times (for the one-letter word case, for adding the 'l', for moving the first syllable to the end), but once they were at this point, most of the students had learned something.

Learnings

Altought this is nothing new for seasoned programmers, having to look back at the learning process was actually helpful for me too - I've made the same mistakes my students did several times during my career, and this may help me to do it less in the future.

Facing any but the most trivial problem, it's actually realizing that:

It’s ok to write something that:

• does not solve the complete problem (just applying one of the required operations)
• does not take all cases in consideration (for example only working on the happy case)

In other words: it is much better to have a solution that is returning something that you know is incomplete/false in a specific way that to have something that you think correct but will require a lot of debugging.

Projects

LeWagon Bootcamp program ends up with the students working in groups on their own projects. This means larger, more complex problems to solve.

Once they had their user stories written, most of them starting asking themselves questions:

• How are we going to compute the user balance from him transactions?
• How can we import those XML data into the database?
• What javascript library should we use to show a sound player on our page?

Good questions, Bad timing

Now, those are actually good questions - they were going to need those answers at some point during the project.

But there lies the catch: most of those questions were related to user stories they would cleary not start right away so even if they needed the answers, they did not need them now.

Project knowledge

When you are working on a project, chances are good that your knowledge of what you need to achieve (technical, functional or whatever) will be increasing as the project advance:

_{graph thanks to http://xkcdgraphs.com/}

Another take on that graph is that the very start of the project is the time where you know it the worse.

In other words, taking a maximum of decisions at the very beginning of the projects means taking them when you know almost nothing about it... which does not look a very good idea.

When to spike?

Now, this does not means I want to throw all design away - I just want them to be tackled when they are useful and not before. A specific and very valid case for tackling a point very early in the project is if there is a doubt that it may be impossible to do. In that situation, a spike should probably be started right away.

As a small example, a student of the promotion had a transaction workflow that involved scanning a QR code. Now, the application itself was web-based, so the question "can I use the phone QR code scanner inside my (web) application" did arise. I encouraged the student to quickly make tests to see what was possible, as this had a great impact on his main feature.

Back to work

Whatever project you find yourself in, when a discussion starts on a subject, the good question is not "do we need to know this" but

"Do we need to know this >now<"

Applying this simple rule on a general basis would have avoided a lot of ultimately fruitless discussions in a significant part of my projects.

Now, what?

The second batch of students from LeWagon Brussels Bootcamp has now been released to the world - we had the chance to have more than 100 people for their Demo Day last Friday.

For most of them, it's now the time to get further with their ideas and hopefully make them grow into companies, but for the ones aiming at careers into web development, it's now time to find a job. This post is mainly a summary of discussions I had with several of them - I hope it can be useful to other bootcamp alumni or young developers in general.

Every job posting requires experience!

Short version: they are lying.

Longer version: most companies will require experience, because they create job postings for what they dream of, not what they need. As long as the market stays as it is (experienced profiles are few, busy and expensive), they most probably will have to settle for less than what they said (or be prepared to pay the price and face a recruitment process that may be very long).

So, what do you do? If you find a job posting that looks interesting, go for it. Don't lie, show the experience you have - you have nothing to lose there.

As a (rather limited) sample, my first developer job was advertised as a position for someone with a degree in programming, 3 years of experience and a certification - I had none of that, and I did get the job.

What can I put in my CV/portfolio?

As a bootcamp student, you have something valuable: A GitHub account with the various exercises & projects you built during the bootcamp. The most interesting part is the final project - the last two weeks of LeWagon are dedicated to build a project of the student's choice (in teams). That's a pretty good thing to showcase.

It's imperfect, flawed and the code is probably dirty, but look at it the other way: you are just starting in this industry - we don't expect you to write perfect code, but your project is showing your willingness and capability to deliver.

Also, by just having some code on GitHub, you're putting yourself ahead of 80% of the developers that have nothing to show (mostly because they did work for companies which are not publishing any visible code).

Of course, don't just include your GitHub profile - tell your prospective employer what to look at ("This is the project we made in two weeks - it's helping climbers to find good spots"). A running version of the project is of course even better.

If you're not out of a bootcamp, same advice: try to build something useful to people around you (your family - your sport club - whatever) and showcase it.

What if I don't know (all) the stack?

If the position is entry level, we expect you not to know much. Actually, I used to say that when recruiting juniors, we don't expect them to know anything at all.

In other words, we are looking for attitude/capacity to learn more than specific technologies.

Taking LeWagon example again, we're teaching Ruby On Rails. Now, if a job posting is about Java Web Development, you are already more than half way there:

• You know the concepts of the Web and OO
• You know HTML/CSS and some JavaScript

Your Rails knowledge will probably not be useful, but most web frameworks I've worked with have some kind of controllers - it's just about finding how they are named.

Again, be honest ("No I never developed in Java") but positive - you learned that full stack in 9 weeks, surely with the support of a team, you'll learn what you need very quickly.

Money Game

Key thing here is that in your first years, you should optimize for learning, not money. Ask about the team you'll be working in - having some senior people there is the best way to learn, mostly by just working with them. I'm lacking formal training in almost all areas that are today my specialty (programming, Agile) - I learned by working with people.

This does not means you should work for nothing (see the next point), but should you have any choice, aim for the place where you think you'll learn the most.

Internships

Here in Belgium, we have a disturbing trend of unpaid internships. Even worse, some companies are actually relying on a never-ending stream of interns to actually fill in some of the low-level positions.

Yet, an internship is still the second best thing after a job - you'll be doing real work.

The key here is (again) not the money: it's whether the company has the capacity and willingness to really coach you. It's not easy - I did that, either onboarding young developers or at one time working with an intern. It easily takes 50% of the time of a senior, and to be honest, it's not giving back the same value (experienced developers can work two, three, five times faster than starting ones).

Best situation for both the company and the intern is when the team is actually a bit larger (2-3 developers), because then it's easier for them to share the "load" and for the intern to get quick answers.

So: look for internships, but try to see where/with whom you will be working. If you're going to learn a lot, the money is not really relevant - it's for a limited amount of time, and you'll be better at the end with a good experience than with some hundreds of euros.

Be sure to extract a maximum value: ask them for a recommendation before leaving, and eventually for some contacts in companies that are hiring - in a small country like Belgium, the programming scene is a small, tight-knit world - we know each other.

Conclusion

Finding a first job as a developer, bootcamp or not, is not easy - but let's face it, it is still much easier than in most other industries.

I realized some weeks ago that I was telling the same things again and again, but also that it was often useful (by their own feedback). This post (and some others to follow) are basically outputs of those various discussions.

Context

Even if I'm mostly contacted for my development skills, I usually start by asking some questions about the business itself - I need it to give any valuable advice anyway. At some point (and often a bit by suprise), the business owner says:

"BTW, we'll start the meeting tomorrow by asking you to sign our NDA"

This was unsettling for me as it sort of suppose that it's critical for their business and a non issue for me - both points I'm challenging in the rest of this post.

On the business side

I've a very unique idea, so I need to protect it

I'm sorry, but no, your idea is (most probably) not unique. We're 7 billions of people on this planet. Chances are you are not the only person having ever thought of that idea ..., and if you are (ie, if no one is into that segment), chances are good that it's because there is not a market for it.

My idea will make the difference

Most startups/companies I know succeed (or fail) because of the way they execute, not because they have a unique idea.

If someone learn about my idea, he'll steal it

If the only value you have is that unique idea, you are screwed anyway - even if you manage to put everyone under NDA, at some point your webapp will be live, and everyone will be able to see what it is.

At that point, if it's just about the idea, anyone could copy it anyway.

Yes, but I'll be first

Great. Tell that to Wordperfect or Altavista or MySpace - they did what Microsoft, Google and Facebook are doing, and they were there long before. Looks how well it worked for them in the end.

Again, it's not about the idea or being first, it's about execution. Google Search (and its associated business model) was not unique nor first - but it was much better executed than its predecessors/competitors.

You are a developer, so you could steal my idea and build it

Again, if the only thing you can bring on the table is an idea, see my previous point.

Now, I'm working as a freelance, and I want to work on different projects. It would not be really smart, career wise, to be "the guy that steal ideas".

More importantly: I'm not qualified to make your idea work. I made projects in very various domains: insurance, meal delivery, publishing, etc... In most of those cases, the business people were specialists of those sectors. I am not. I could build the software, then what? I'll be unable to sell it/market it/communicate with the audience, and that's the most critical part.. Trust me - I tried to build a software in a domain I know nothing about (HR), and it did not turn well.

On my side

It's a simple administrative document

No, it's not. It's a legally binding contract which may bring me before a justice court and possibly to pay a lot of money.

It's a very standard document

I don't know. Maybe it is, maybe not. I'm not qualified to judge, and if you are not a lawyer, you're not qualified either. I would need to ask my lawyer to read it and give me feedback. This takes time and money that I prefer to spend respectively on building software and eating good food or going on holidays.

ROI

I start most collaboration by proposing to work on the smallest piece of software I can. This means that we can learn to work together without you putting in too much money. At the end, either it works well and we continue, or it does not. But you still have a first working software to show to your users and you have the ownership on the code to get along with someone else.

Getting my lawyer in and getting the risk of a law action are just not worth it if we're talking about a couple of thousand euro in revenue. Even if I win, I'll lose more in the process (in money but mostly in time/energy) that what your business could bring to me in revenue.

It's your business - you have the right to put any requirements you judge necessary to anyone wanting to work with you, but on my side, I can just decide to pass the opportunity.

Some final words

None of this means I'll be bragging around about our discussion - if you ask me to keep it quiet I will. I do think you should talk about your idea to as many people as you can, but that's for you to decide, not me.

I just hope it can help shed some light about why an NDA is something that is both less needed and more serious than most people seem to think.

In addition, for all the conviction I have that ideas are worth nothing, I think that as a business owner you have so much more to bring - mainly a knowledge and contact to your audience, a drive to make it happen, probably connections needed, etc.

So don't think your idea is the only thing you have. It's not.

The Grim Situation

Software development is known to be pretty much a waste - as an industry, we are known to deliver late, badly and expensively. According to a McKinsey study, the mean software development project is 7% late, 56% over budget while delivering only 44% of the functionalities.

This is due to a lot of factors. One factor I want to clarify today is: "bad customer/developer communication" - and what you as a business owner can do to make my job easier.

The problem

Basically, we come from very different worlds. We both have our own jargon, expectations and implicit truths - as every business has. It means that explaining to me what you want is a very dangerous path:

• You'll withhold some information because "everyone" knows it (implicit knowledge)
• I'll misunderstand part of the rest, due to my own (flawed) vision of your business.

Complete Specifications

For years, we tried to solve this using more detailed specifications - up to thousands of pages. Although well intentioned, this did fail in a quite spectacular way for various reasons:

• Even writing do not prevent you of a bias
• I'll still miss some part of it (especially if it is big)
• The amount of work required to create it make the project both expensive and very late - before even starting
• By the time of writing the specifications, the request can again have changed.

While relevant in highly controlled environments, this process is most probably not what you want.

User Stories and Collaboration

Why User Stories?

The Agile movement advocated a different approach, less based on solving the user/developer communication mismatch and more on ways to cope with it. The basic assumptions are as follows:

• The bigger the functionality, the more complex it will be to describe/explain, the bigger the chance of misunderstanding
• The bigger the functionality, the longer the time it will take before it can be demonstrated (and validated)

Template

This leads to a simple (at least in its formulation) description:

• Try to keep features as small as possible (so the areas of possible misunderstandings are the smallest possible)
• Be sure that every single feature can be observed by a non technical user

The result of this is what we call a User Story - a simple template that describe a feature in a single sentence with the following format:

As a user category I want given feature so I can enjoy benefit

Some samples for a banking system:

• As a customer I want to be able to transfer money to another account so I can pay my providers
• As a customer I want to see my previous transfers to see where my money went
• As a customer I want to see an overview of all my account to get my balance in a single action

Benefits

As the format constrains you to a single sentence, it forces you to divide your big blocks into small ones. Not an easy process, but a very valuable one as the risk of misunderstanding becomes very low - and there is more:

• The story focusses on the user - who he is, what he wants and most important why (the benefit)
• As the story is "user observable", you'll have something to see/test after each story
• The simple format allows for easy agreement about whether something is done or not
• The small size allows to get a good vibe about the project process, as stories are typically developed in a couple of days.

Priorities

Once you have your list of stories ready, you can write them on post-its or their digital equivalent, Trello. You do not need all of them to start the project. With the first 5-10, you can start.

Now is the time to prioritize them, and the best way is a simple order: move the most important ones at the top, and work down.

Ready!

With this prioritized list in hand, you can come to a development team with a clear view of what you want. We'll typically run through the list together, asking any question we could have. Barring any technical reason to reorder (I may need to develop the user Sign Up story before being able to do for example Saved Filters), we'll then start working in order - taking the one from the top of the pile first.

Conclusion

Making my job easier is actually a good way to help me focus on what matters to you - hence delivering more value for your business.

• Those are separated systems
• Let's make an integration between them!

Last week gave me a nice example - my parking door.

The Parking Door

I've recently moved to a new appartment in the middle of Brussels. Being a new building, it has a mandatory parking (public parking space is in short supply in Brussels) - but as the building are quite narrow, it was impossible to build a ramp.

Instead, we have a "car elevator" so that cars can enter the parking at street level, go down with the elevator and then park in the underground parking.

I actually don't own a car, but I'm using the parking for my e-bike, so I've been using it quite a lot.

Here is a little schema about how it works:

The problem

So - this is a typical example of a clever solution to a set of constraints:

• We have to have a parking
• We don't have the space for the usual solution (the ramp)
• We need this to not cost an arm and a leg

Now car elevators (at minimum small ones like this) are rather unusual - so we're a bit into new territory.

The good news is that the two main pieces exists:

• Doors than can open and close with a remote control
• Elevators able to manage "heavy" weights

The bad news is that we now have a system made of two independent pieces.

The specification

So there is a certain number of rules that the system need to respect:

• The street door can only open if the elevator is a street level (don't want the car to run into a hole)
• The parking door can only open if the elevator is at parking level
• The elevator can only move if both doors are closed
• No door can close if a car is below one
• The elevator can't move if something is too close to either door

The problems

The first thing I learned when I arrived in the building was that "getting in and out the parking is not simple" - we also got a two pages guide about thow to manage that system.

Two weeks in, while the systems mostly seems to work, you see things getting weird once in a while:

• The street door almost got on the car of a visitor
• If one of the door does not close or open completely, the whole system become unresponsive - effecively blocking the elevator, possibly with the street door open.
• When this happen, a combination of actions + waiting time generally ends up in the door closing, and the system resuming normal behavior
• No one is clear on what that combination of actions is
• The street door did fall on the car of another tenant

Now again - the providers for both the doors & the elevator looks like decent companies knowing what they do. Individually, they probably work.

What about integration

This simple example showcase a good set of elements to have in mind when talking about "integration":

• Having two independant, working systems does not means the integration part will work as well (or at all)
• Integration often "leaks" to the end user in the form of a set of disjointed interfaces resulting in a poor user experience
• Having two systems "talk with each other" is not a given - especially if those systems have not be created with that purpose
• The more complex the integration, the more source of bugs
• Even if the integration "works" (achieve expected result) it will most probably be awkward to the user (the two remote controls - or in software, having to log separately in two systems)
• Bugs are especially probably with complex interaction depending on the state of each sub-systems

Conclusion

This does not means we should never use any integration, more that it comes at a cost - in budget or frustration for the end user.

In several recent cases, proposing a single system (even with significantly less features than what the combined system could provide) was actually in the end a better solution.

As someone said recently "Integration are more like organ transplant than lego blocks" - so use it with care.

After 5 years as lead dev then CTO at Bluesquare I’m currently looking for my next job.

What I like? Generally companies that have social impact - health, education, climate, poverty reduction or anything where I can feel that my work contributes to helping people.

What can I do? Pretty much any role in a development team. I’ve spent the last 15 years between development and engineering lead - I’m interested to get back into more coding this time but I always have an eye on how the team is working and how we can get better together, regardless of my exact position.

I’m generally tech-agnostic - I think what matters is the value we produce, so I generally favor mature, boring solutions (looking at you Postgresql). I’ve been using Java, Ruby, Javascript and Python in professional settings.

I’m also interested in working more with data - being an economist by education and working on a lot of data issues means I’ve developed a lot of curiosity in that area (including working more with Python/pandas/etc).

As far as experience, I’ve worked with companies from 1 to 3000+, including cofounding one. I’ve been a sole developer for new startups & led teams from 2 to 20 in various industries.

So, if you have something like that at your company, or hear about it - let’s talk!

Thanks!

Twitter incredible strength is allowing you to follow, read ("listen") to other people experiences, without intruding (remember: you don't have to reply/comment on everything - actually you don't have to reply/comment on anything).

To give more concrete examples, when as a white guy working in tech I discovered (initially) one horrible story about what is meant to be a woman in this industry (if you did not yet go read Jessie Frazelle [https://blog.jessfraz.com/post/this-industry-is-fucked/]("This industry is fucked") - there are a lot of others, but that one is short and set the tone pretty well), I looked more closely at what the other women I was following were saying. This helped me realize how common the case was (at some point I pretty much looked specifically at each - and found some kind of story in every case...) - from the people experiencing it themselves.

Since then I've tailored a bit my Twitter list to serve that purpose - give me insights into what other facing, generally people with less priviliege than I have (women, persons of color, disabled people, junior developers, etc) - something that can be difficult to experience directly.

In my ideal imaginary world, I'd just put some words down and be down with it - with minimal overhead. My current Jekyll setting was working but a bit cumbersome so I started a review of "what to use as a blog in 2021 as a developer that does not want to tinker nor host". This proven be more complicated that I expected:

• Medium: A winner on the "zero-config", but Medium general model concerns me and I've seen them paywall free content. So, no.
• Wordpress: I did consider that one more than I'm willing to say - thinking of the "Wordpress.com" part (I don't want to host it either). I finally found something before going there, so that's good.
• Ghost: Looks way too elaborate for what I need - "Turn your audience into a business" looks a bit too ambitious for me.
• Micro Blog: I really wanted to like that one. Looked perfect for me, so I went with it... before getting so many errors with weird messages when moving my content there that I had to just delete everything and look for something else.
• Eleventy: This what worked for me in the end. Some detail below.

So to be complete, this is using Elventy with a theme/starter called Eleventy Duo created by Yinkakun (thanks!). The setup include an easy and free way to deploy on Netlify and even a link to Forestry - a web UI that can even commit to GitHub.

Thanks to Netlify's redirect capabilities I was able to keep my old urls working.

In a nutshell this gives me what I need:

• A ui to edit/post if I want to use it
• A git repo back end so I can move again if needed
• Markdown document as content (I love markdown)
• A free deploy on Netlify
• A nice simple theme with most of the required bricks in place (RSS feed, links, pages & posts...)

I'm quite happy of the result for a couple of hours of work altogether. So now I 'just' have to get content here again I assume.

What's Osoc? It's a yearly four weeks event organized by Open Knowledge that bring together partners, students and coaches to deliver open source projects. Partners are companies or organisations that have a project idea and want to have a team work on it. Students are, well, people busy with their studies (but usually free in July, hence the timing) willing to experiment on some group projects - mostly with IT/computer science background, but we saw a lot of people from design or communication background too. Coaches are people working in the same areas that are there to help the students deliver.

My first surprise arriving at the info session was that coaching was actually "full time job" for the duration of the program - the second was that it was paid (students are paid too). How? The partners bring the projects, but they also bring the money. This is a boon for coaches (this can still be "billed time" which is easier to find as a freelance than pure pro bono) but also for students (they don't have to pick between the experience and earning a bit of money for their holidays).

The experience was really impressive - led by a couple of benevolent dictators (I think the official word is "Coordinators"), the Osoc machine is well oiled with the experience of numerous edition. While Covid forced it to be fully online for the second year, it really did not disrupt much. Partners comes with detailed projects, students are selected and put in groups that make sense to deliver them, and assigned coaches with the skills they need.

For me it meant being paired with Xavier that has an extensive product and design experience to help four students to deliveer a Solid/Linked Data proof of concept brought by IDLab.

The result is here and the journey was a blast. With a good and battle tested structure provided by Osoc, nice and available partner and a very motived group, days did fly by on a flurry of activities - learning new technologies, discussing features and deliverables with partners, coding and even some documentation.

In a nutshell, this is an incredible experience that I would recommand to anyone working in or near the software industry - coaching is a super fun activity (it's helping as much as you can without ever doing anything the students could do - and those could do a lot), and there is a lot to learn there. Did I said it was paid, too?

Thanks a lot to benevolent dictators Astrid & Miet, to my co-coach Xavier, to Ruben & Pieter from IDLabs and mainly to Cyrille, Lin de, Jerry & Romain - you did an impressive job and working with you all was a pleasure.

See you next year!

My main problem is that, well, data has a structure and not having to worry about it is super fun - until you want to do something meaningful with it. Students have names and first names, Orders have a OrderItems that have quantity and prices, etc - and generally if they don't, Bad Things happen. I'd ever go as far as "not only is most 'real world' data structured, it also tend to be relational in a lot of cases".

So if the structure is not managed by the database, it will need to be managed somewhere else - either in the application (possibly via an ODM like Mongoose or Djongo, probably via specific validations) or worse even in the UI. I don't know many applications where the end users wants to deal with unstructured data on their side. We tend to name stuff we show on the screen and organise it a bit so that it make sense for the person using the application.

My feeling is a sort of eternxal cycle of:

• This is wonderful we can make our database evolve so fast, everything is getting in!
• Cool we can accept users even without emails - schemaless FTW, no migration needed!
• Doh looks like our last mailing did not go well as half of our users had no email at all
• Let's add some validation for this not to happen again
• Also would be good to check that each user is properly linked to an account via this "account_id" field we added
• ...

In other words: what feels (for a very limited amount of time) as a blessing become a curse really fast, ending up into some kind of partial, erronous, inefficient custom reiplementation of a relational model.

I'm going back to PostgreSQL.

So I was both eager and a bit afraid about the experience - which ended up being one of my best teaching experience of those last years.

What I learned - in no specific order:

• Teaching code to blind students is much less different than teaching any group of juniors than you may think
• While I was not used to working with blind students... they were quite used to work with non blind teachers. The first thing they told me was "We're used to that - we're going to help you, no worries".
• Blind people use "see" in figurative ways all the time (ex: "do you see what I mean") - so you can too, it's not ableist or offensive by any means
• Screenreaders are not limited to text to speech feature - they also provide for example alternate navigation options (for example to go from link to link or tabs to tabs on a webpage)
• Using screensharing and remote access to help them debug their mistakes gave me a better view of the way they interact with the computer, roughly:
  • Screen readers allows them to get whatever in the screen read to them. Alternatives exists (Braille displays such as the supervario).
  • Fun fact, most of them have their screen reader at 1.5 or 2x speed - you get tired of listening to all links on a page
  • They either type (I'm not looking to my keyboard either, why should they need it?) with a echo system or dictate
  • Keyboard shortcuts are obviously critical
• I had to replace my usual way of "explaining things while I type them with my screen sharing open" - this means dictacting more code, alternating between the exact dictation and the explanations that goes with it. React is a bit of a mess in that regard due to the abuse of symbols (<>?:{}()[]...).
• Any interactive command line is a mess (for example expo init myapp) - but generally alternative exists to pass params directly (expo init -t blank myapp in this case) - once I got that I just looked always for those kind of commands.

On the "fun facts":

• Using a combination of shortcuts, screen readers and braille displays, I've seen several of them navigate code as fast as I can
• While we were working with https://opendata.bruxelles.be/ (a site with all open datasets from the city of Brussels where I live) one of the students exclaimed "This site is far too crowded - it's difficult to navigate". That's exactly what I thought too - so when it's bad it's bad for everyone - but worse for disabled people.
• I would be ready to bet some money that I could have some of them work (at junior positions) for companies and that people would need some time to realize they are blind (in this "remote new world" that we have nowadays).

I really think this experience will have me approach accessibility better in my future missions.

So thanks to Harielle from Eqla for trusting me with this and mostly to Sophie, Bruno, Matthieu, Simon, Isaac, Mounir, Yves and Ibrahim for their energy and the warm welcome they gave me.

While the industry is still good, I can't hide from the main thing that did allow me to get into most of those positions - or at least to be given a chance to show my skills - networking.

While I'm an extrovert, I never liked networking. I've trouble going into events where you have to somehow awkwardly (for me) present yourself to complete strangers in order to end up with a business card or a LinkedIn connection.

I'm just lucky that twice in my career I end up in positions where networking was part of the job.

Once out of necessity - I co-founded a failed startup, but we played the game according to (what we thought were) the rules - we joined an incubator, developed friendships with the other founders and useful relations with mentors - generally well established CEOs (at our little Belgium level at least).

Once out of pure side benefit. I worked as lead teacher at LeWagon Brussels on and off for a while after having started the chapter here. After some years, it means that my students' students are now senior developers or founders in hiring positions.

Both of those are now years ago - more like 5 or 10 than two. But when I looked for a job at the start of 2021, that network was a better provider of opportunities than any skill or experience I had.

I'm not saying that it's fair (it's not, mostly it's privilege). In a better world, hiring decisions would be done solely on skills (hard and soft) - that does not make it less true.

I'm not saying it's fun either (I generally dislike networking personally) - that does not make it less useful.

My point here is to simply not underestimate its effects on a career path - yours or someone else. The "most successful" people around are not always the smartest/hardest working. They are often the best connected.

It was plagued with all problems of a system outgrowing excel:

• Duplications difficult to avoid
• Requires to make updates in multiple places
• Consistency depending fully on the person's discipline

So I started to think - why is this not a software? The project is complex enough to warrant it.

The fact is - this imaginary software would probably cost 250 to 500k€ to build in more than 2 years and generate a lot of weird bugs.

Even assuming it could be done - it would probably be inferior to the Excel sheets in a key way. This Excel sheet is a mess - but the project manager can still decide to update it needed. They won't have to ask a (probably external) development team for things as simple as:

• Changing the price computation rules to take into account 2% of inflation in 2021
• Adding an option to the material drop down list for another type of concrete
• Create one more chart showing the total paid per contractor
• Batch update a lot of values with a smart cut & paste

In other words - it would remove the main user agency, moving it to a costly, lengthy, blurry process.

Not every software is worth writing and beating an Excel sheet is easier said than done once you factor the incredible flexibility it brings.

Yes, it's messy. But it works. And let's be honest - that imaginary software will surely be messy too.

I guess this sounds harsh, so I'll elaborate a bit.

What I get on a daily basis from recruiters is a version of this:

"Hi Martin, I have an incredible opportunity for you in a very disruptive company using blue and green technology. They have a very dynamic environment and offer a competitive salary. Can you give me a number I can call you on".

Generally missing are:

• What the company does
• What the team looks like
• The salary or rate range
• What's the work life balance

In a nutshell - I don't get any useful element to be able to even see if I could be interested. Instead I get a sort of template text with two technical words lost in the middle and a demand for my time.

I understand where this come from - if you as a recruiter starts saying anything meaningful about the company (not even saying getting me in contact with them), I'll probably be able to identify them, and your whole value disappear - your service cost a lot to the company and actually to me too!

But Martin you are not paying me? Well - maybe not in money, but in time. Instead of being able to talk (possibly convince) a future boss or colleague, I have to discuss with an intermediary with actually very limited knowledge about the job - and also a very different set of interest.

Generally you'll be paid (in the tens of thousands!) by getting people like me to sign contracts - so you need me (and a lot of other people) to sign 1/fast 2/for a lot of money if possible. The thing is, I'm generally not in a hurry and more interested to know/understand more about my future team and company - something that makes this relation very shaky.

When I look for a job, what I could get from you (I'm guessing as none of those ever happened) is three possible things:

• Get me in contact with jobs I could not reach myself
• Manage to "sell" me for an higher price that I could
• Get me better information about positions or companies than what I can find myself so I can find a job more adequate to what I want

From experience - none of those ever happen.

• Companies have no incentive to "hide" their job post in a very challenging job market.
• You never take the time to know me well enough to be an efficient agent (and hence able to sell me better than I can do without going overboard).
• Getting better information requires to get the company involved and at that time again you become useless to me - I prefer to cut out the intermediary.

For some "usual" questions:

• "Looking for a job yourself take time": It does indeed, especially as I tend to be a bit picky. But I'm not a company - I have only one "me" to "sell". I can afford to take a bit of time to find a place I'll be happy.
• "I'm different": I wish I could believe that - but finding out takes time. So if you really think so and want a call - pay me 250€ for the call. I promise I'll join, and if it's useful, maybe we can work together. I made that offer several times - no one ever took it.

So - I won't accept your invitation. The good thing is - you can probably find someone who will. I see that the recruiting industry is still alive and well - as mind boggling as this could be for me.

Martin

As a sidenote - this mostly do not apply to company internal recruiters - then tend to understand their company pretty well and are more closely related to the hiring team so there are much less friction in the relation.

An important thing first - having used Asana, Clickup and a couple of others, most critisism about Jira (mine & the one I read) is not really about Jira but about a category of software - Task Tracking software - that Jira has just become the embodiment of (a testament to Atlassian impressive success in the area). So replace "Jira" by any other task tracking software you use if you want.

Now why do people "hate" Jira? Well first as developers we love ranting about software - even better when it's about software we have to use (versus software we pick).

My current feeling (after some introspection) is that it's not really the software I despise - mostly what it represents.

Jira is all about creating a system of "tasks" that can be assigned to people and then completed. It's not about "tasks" - it's about "things that need to be done" - about work organisation - and work organisation is messy.

It's messy because we need it but it never really feels good. Even when I work alone, if I don't have a system of tasks, I'm not sure what I'm doing. I need to plan a bit (else I'll forget things when I need to pick them up again), and if I want a remote chance to achieve something in a set amount of time, I need to split the work up. I need to be able to track my progress. It's already hard to do it for myself:

• Too coarse and it becomes "finish project A" which is never moving, so give a feeling of no progress
• Too detailed and it becomes a myriad of super small things possibly with no clear output - and I loose the big picture

It's even worse when this is done with a team - even assuming the best collaboration, writing tasks for someone else is complicated - it's all about communicating intent without going too far on the "step by step". After all, if I have every step figured out in a development task, I'm probably well advanced anyway (and the person I give the work to may have a different approach that may be as good or better).

It's messy because it's a vain attempt at putting complex and uncertain human collaboration efforts (ie: projects) in clean well separated boxes that could be "ticked" as done - something that we know is not really possible but that we need anyway.

So we settle for the middleway - an imperfect representation of our work, whose shortcomings are obvious and being humans, we rant or complain about the tool because that's the easiest piece to criticize (plus the tool ego will survive).

In a way - the complains are part of the way that system works. I've been "the Jira guy" at several companies already - because despite all the flaws, I still think we are better with a task tracker than without one - as long as we can complain about it.

Thanks to getting some days off between two missions, I've been able to take one card of my "project idea" board and actually implement it. The result is "newscheck" - a web app that analyze the gender diversity of belgian headlines.

The usual problem of a "pet project" is quite similar to a startup first product - you need to ship something really fast, that still need to be "good enough" to at least attrack feedback. Actually, in my case, the "pet project" is a sort of "exageration" of the MVP project - I need to get it out "now" as there is a good chance the time window will close.

That first version is around 12 hours of work - for something that qualify as an MVP in my mind:

• It do something useful - well enough to be used
• It's usable - won't get any design award, but it won't drive people mad either

More importantly - it did attract some interest and feedback, which is probably an even better validation.

Now, I tend to think of myself as someone that cares about good code and good practices around it - I mean things such as unit tests, features branches, staging environments, etc...

Looking back at newscheck, I pretty much thrown everything away - I was just trying to get something out as fast as possible. In order to not call this "dirty work" or just "yolo", I'll call this "prototype mode".

Prototype mode

This is a bit "what I do when coding alone with a very severe time constraint". Some things are part of my usual workflow/tool set, some are not. As usual, this is biased toward "web development".

• A good "heavy" web framework - I mean something like Django, Rails or Laravel more than Sinatra or Flask or Express - generally something that get you a lot of things out of the box and with a vast ecosystem (like: you don't want to spend 30 minutes on the user login part, having an admin interface helps too)
• Simple, "git push" based hosting (Heroku typically)
• Postgresql - could go easier with like sqlite, but Heroku manages PG as well and...
• Postgresql JSON fields. I'm quite sold on the relational vs NoSQL model, but having the option to put some semi-structured data without having to migrate or thing the model out from scratch is coo
• No unit test - manual test aka "is the feature working the way I want it"
• Some UI toolkit - ie something with components. I'm quite happy with my Tailwind UI purchase for this
• Trunk based development - good news is that is actually a best practice - even if I'm mostly using feature branches when working in a team (sometime even when working alone for the "easy compare")
• Working from the local machine on the production database - this helps iterating very quickly.

The general idea is to get a decent façade (features, UI) on what the end user can see - and anything that just works behind it.

If you want to go fast, go alone

"If you want to go gast, go alone, if you want to go far, go together"

One of the main goal is to make possible for this to be a "one person project". Most of the shortcuts are related to my own shortcomings - I'm mostly a backend developer, hence:

• Using something like Heroku to avoid the hassle (and time) of setting up a server and managing it.
• Using a UI toolkit to get something decent without having to call a designer.

Depending on your own strenghts, it could be the other way around - as a front end developer with good design skills for example, it may be good to look at things like firebase or other like that that can give you a functional backend/API with minimal coding.

Downsides

While I love that (very short) phase of a project where could can release in hours, not days, a lot of practices are there for a good reason, and this is 1/dangerous 2/would fall apart quickly once you need to work with a team.

Dangerous mostly because any error will probably result in something broken on the user side - this happened several time with newscheck (like "I did not test what would happen in the dashboard if a source had no analysis yet). The idea behind the "prototype mode" is that you can break things - and also that you can fix them in minutes.

Would fall apart as once it's more than a single person working, you'll need either work separation (feature branches) or a way to know you did not break anything that does not rely on the end user (like, tests) - probably both.

Working directly on the production is a good way to a quick death as a startup - as mistakes will happen (when, not if).

Leaving management

My main (work) update of the year was clearly my decision to leave my job as Bluesquare's CTO. Not only I had been there for more than 5 years, but this decision went further than a simple position change - what lead to it is my (long matured) goal to leave a management role and get back to more technical stuff.

This was my own version of moving to some kind of "Individual Contributor" ("IC" as you see in a lot of US companies).

TL;DR; this turned out to be a great decision.

What freelance means

I've been a freelances (fiscally speaking) for almost 10 years aldready, but I've always looked for long term opportunities - with the occasional teaching or advisor short mission. My goal when I started to look for work this year was no different.

Due to a combination of opportunities, customer decisions and personal ones, I actually worked with more (different) customers this year than maybe in the last 7 or 8 years, with missions sometime as short as a couple of months.

Despite my initial feeling that I needed a couple of years to be at "full speed" in a new environment (knowing the code but also the culture, the people, etc), this also turned out great both for me and my customers - being able to bring a fresh perspective, learning a lot from new people and delivering value even during short term stunts.

Work life balance

An important goal too was to get a better work life balance. Between a C-level job, kids and a pandemic, I only realized after leaving how close to burn-out I was. I'm still quite driven about my work (I need it to be able to invest myself in it), but I wanted to be able to close the laptop on the evening and not have work as a never stopping background process in my head.

Putting this upfront in interviews helped "set the stage" - once you are into workholic habits in a specific position, stepping back is incredibly difficult.

Pretty much all companies below got some version of that message very early in the interview process:

I'm generally motivated about my work and I want to deliver value - but I've a life too and I intend to keep it. At 5PM I'll close my laptop, go fetch my kids at school, and open it back the next morning around 8AM. The day there is an emergency, I'll still do it, but I'll reopen it around 8PM and help however I can. If there is an emergency each week, I'll leave.

This message was generally positively received. In a single case, the company admitted that emergencies were indeed the norm - so we just stopped the process there, no harm done (I actually told them I appreciated the honesty).

Luxury and being picky in this industry

As far as I can tell, the industry has never been that good for people looking for work (at least on the senior side). A lot of companies are looking for people to join them, which means that as a consultant I could decide to be "picky".

Where it get interesting is that you can be "picky" about anything you want - technology, money, culture, ... - or in my case, social impact.

With a few exceptions, I almost only worked for companies that had some social impact. That does not means they can't be for profit, more like "Do I think we are better with that company in the world".

This was again my criteria for this year - while not impossible to fulfill, it does put 95% of the companies out (including banks, marketing products, SEO stuff and obviously anything remotely connected to blockchain).

Fortunately, there are a lot of nice people wanting to make a difference in the world - among them the companies below.

Missions

So what did I actually do this year? Here are the main missions.

IOS Press

IOS Press is a small publisher of scientific books and journals. This is a 2 days a week mission but I liked the company so I asked other potential customers if there were ok for part time. While it felt initially like the "side job" to whatever I would find, it turned out to be a great opportunity with good long term potential.

The best definition of my role there is "technical handyman" - IOS Press is in the process of a major IT transformation, moving from outputting PDFs to creating a whole knowledge graph of their 35+ years of publication.

This means I had to be able to work with a lot of different technologies and languages - from bash and Python to manage a ML-driven pipeline to React and SPARQL to consume the data via some Java for matching algorithms and Drupal/PHP for integration with the content.

Described like this, the job posting would be downright scary - but it's also what I like here - it's the variety of five jobs built in one, with a management that understand that things can be learned but also that it takes some time.

It's also the job which is the most at the opposite of my CTO job - I'm the technical guy here, and most weeks my meetings are limited to a single 20 minutes back and forth with my boss about my progresses and the next goals - which is a welcome change.

Shayp

Shayp is a company that makes automatic detection of water leaks. It's my first drive into an electronic, IoT driven product. Smart devices allow a steady flow of data, which can then be analyzed and even pushed to an ML model for automated leakage alerts.

Seeing the output of your work as "meters of water spared" is a nice feeling when getting back home on the evening. Together with the development and data science team at Shayp, we did a major migration of the web application from Pyramid on Mongo to a much more standard and robust Django on Postgresql stack. I'm a big fan of PG and more generally of mature, well established solutions, leaving the innovative part where it belong - in the business.

Among other, I discovered how React + OpenAPI + Orval + Antd can be a very productive combination on the front end - getting the whole "data fetching" part almost 100% generated, combined with Ant Design massive component libraries made the development super fast.

Skills Union

Skills Union provide curriculums and training in Growth Hacking, UX/UI and Software Development - with a twist. Thanks to parternships with universities, the various trainings provides actual University credits valid against a master.

While this was a short mission, having to design and develop a whole curriculum with a team of instructors was a great challenge and a new experience for me. While material exist online about pretty much everything in my area of work, getting the good rythm, balance between lessons and individual work, coming with good, progressive exercices while pushing multiple abstract concepts in an accessible way was an exciting puzzle.

Bluesquare

Funnily enough, the year finished the way it started - with a mission for Bluesquare, my former employer, dedicated to help the WHO to coordinate the work of various IT companies to deliver a massive Covid geared product, going from field data collection all the way to the dashboards and analysis.

WHO is a fascinating organization, whose role has become better known than before due to the pandemic. Developing a product that could be used from rural areas in Cameroon to South American metropolitan areas and pretty much anywhere in the world poses very specific challenges that are not usually found in the industry - and the impact is difficult to overstate.

Teaching/Coaching and others

Aside from those, my freelance status and some lucky chances led me to a few other interesting opportunities.

Blind Code

This is probably my personal highlight of the year (workwise) as per "where I learned the most on a personal level". Via some colleagues, I was put in contact with Eqla, a non profit organisation aiming at improving the daily lives of blind people.

More specifically, they launched Blind Code, a coding training for blind people. While I'm not new to teaching people to code, it was my first time doing so with blind people. I did blog about it already and I'm really thankful about the experience.

Osoc

I coached at Osoc, something I also wrote about. Combined with Blind Code, this managed to scratch my coaching itch this year, and also provided opportunity to work with more people from Flanders (the startup world is quite divided in Belgium and as such I don't know many developers from the North).

I'll clearly try to be there next year.

As a fun fact, this is a job I found by answering to a... tweet. My work on Linked Data at IOS Press was also quite useful for the project I followed there and let to the...

ABB Hackaton

Speaking of working with the North - ABB or "Agentschap Binnenlands Bestuur" (Agency for domestic governance) is a part of the Vlaams Gewest that is dedicated to strengthening the link between (local) governments and citizen - notably via open data and tools.

After an initial contact following the Osoc coaching, I participated in a hackaton organised by ABB. Our team tried to improve on a complex process between local and regional governements, involving Linked Open Data ("LOD").

As a way to get to know a team/company (and vice-versa), this beats endless interviews or code challenges handily, and I look forward working more with the ABB next year.

Tapio

I've a small but long term commitment in Tapio, a company helping businesses to compute then compensate their carbon footprint. I'm a technical advisor to Tapio - which is less fancy words means that I'm playing the sparring partner to the company's CTO. Having been there, I know the position can be lonely, and I'm happy to provide someone to talk to.

Personal project

I blogged 12 times - not bad. I also did a personal project for the first time since Effin Bot. As many developers, I've a good bag of projects I'd like to work on - but generally never do. This is something I've made my peace with - not every aspects of my life need to be related to coding, and it's ok to only code at work.

Some planets did align in December as I had a short break between missions, leading me to develop Newscheck.info - a website showing the gender balance (well, imbalance) in Belgian newssources. This got a bit of attention, and I intend to find some time to work more on it next year.

Wrap up

While I often reflect on my career, this is the first time I do the "year in review" exercise. Listing all the things I've done, I'd say not bad for a year with a pandemic and two small kids at home - knowing that it happened also while readjusting toward a much saner work life balance.

I could'nt be happier with my decision to step down from management, and I'm looking forward to this new part of my career.

This year also cemented my position as a "specialist in nothing" - I'm using mostly "what's there", I welcome learning new things and I don't really have a "stack of choice" even if Python seems to come close to it those days. It has led a customer to call me "a generic dev" and I decided to wear it as a badge of honor.

See you next year, and until then my best wishes to you & yours.

I blogged last week about my 2021 Wrap Up - this is also a good opportunity to look at what I've learn in this first year of "back to technical work".

A few months ago I started a small Excel file, putting the date and the technology each time I learned something new - which is quite often.

Thanks to that file (and some sketchy souvenirs), I was able to put some things together here. Like many people, I don't always think I'm learning that much - until I do this kind of exercises.

So, in no specific order, some things I learned this year - technical edition.

Hooks first React

I'm not new to React, but I had to create a couple of new applications this year (plus teach some React at BlindCode) so I did wrote a good amount of "modern react" - which means functional components and hooks. While none of my apps are that complicated, I was quite happy with the results:

• No class components at all. No "didComponentMount" or anything like that.
• State management with useState is a breeze...
• ... even more combined with useEffect for things like API calls

Result is smaller, cleaner and more readable code - something that make me love developing applications with React even more.

React Native

My mobile development experience is quite limited - as a mostly web dev, technologies like cordova or react native that allows me to use my web knowledge are a godsend. I taught some React Native at BlindCode, so I had to learn it too.

Thanks to React Native and Expo we were able to create a couple of simple apps, interacting with various Open Data APIs. Aside from reusing my skills in React, I appreciated quick development/test cycle, with Expo providing an easy deployment on mobile devices without having to deal with the App/Play store shenanigans.

I understand none of those technologies are as good as working directly with the native environment, but they are easy to start with and productive - something that's usually critical in the scarce, startup environments I tend to work in.

Linked Data

This is more obscure, so I'll explain - Linked Datal is a W3C initiative to publish data in a way that make it easy for them to be connected with each other - even with other providers. In concrete words it means using URI as records identifiers and graph formats like RDF as data structure.

While I appreciate Linked Data goals, I still feel like this is reinventing the wheel on the technical side:

• New database engines
• New query language
• New API standards

Anyway, applying my own advice of "using what's there", I did dive into the Linked Data world, learning:

• SPARQL - a graph traversal query language to retrieve data from a Linked Data database like...
• Apache Jena - the leading open source Linked Data database. While the community there was incredibly welcoming (ask a question on the mailing list, get answers by people writing books on the topic), managing Jena and getting clear profiling information about query was quite a challenge.
• GraphDB - another Linked Data database, created by OntoText. Not open source at all, but there is a free version. I gave it a try one day after yet another bad fight with Jena, and ended up with much better performance - so I switched to it. In the meantime I've learn that most people actually use Virtuoso - yet another commerical but with some free version engine.

I'm still wondering if a "Linked Data on top of existing technologies" would not have been better (PostGres, SQL, REST or GraphQL, etc). The problem with "starting from scratch" is that you compete against incredibly mature and efficient solutions - and also that your community is very small in comparison. So you have very smart people working to solve problems that have been solved 20 years ago by much bigger teams.

Going Linked Data still look like a risky bet in that regard - people I've spoken to in the area are convinced it's going to best best big thing. I'm not sure - but heh, better this than blokchain.

Solid

Sort of similar but different - our Osoc application was Solid based (by request) - pretty much a proof of concept of what an image library application could be in a Solid world.

For those that never touched it, Solid is a specification about data interchange with one key aspect - the data stays under the control of the person (versus Google or Facebook). Fathered by none other than Tim Berners-Lee, Solid makes a lot of sense technically and ethically.

Creating the app was mostly straighforward - in a way it's defining a Solid-compliant data model then create a client app using the existing Solid APIs.

My doubts here are more on the market side - none of the big players have any interest of using or even tolerating this approach - I don't see them going there without being forced to, which looks unlikely.

Mongo

Among others I was handed a Mongo backed web application - I also wrote some Mongo courses, so I finally (?) worked a bit with one of the most popular NoSQL database. I don't know if this comes from the bias of having 20+ years of familiarity with SQL, but I found that writing Mongo queries had quite a steep learning curve.

Basics things are, well, basic, but more advanced cases get complex fast when dealing with non trivial aggregations. As with SPARQL, the tooling is also not as good as in SQL (ie: EXPLAIN & others).

I know Mongo can be quite fast - but I'm still unconvinced by the "benefits" of schemaless. I used Mongoose (a JavaScript/Mongo ODM) for some lessons and while it is quite nice in itself, it's a good example of "if the schema is not in the database it will need to be somewhere else" - and I'm quitte happy to have it in the database generally.

Linux admin and the command line

Due to taking over some admin work at IOS Press, I had to improve a bit my Linux administration skills. I used sed to replace some lines in a very large CSV, find and grep in combination to retreive all files containing specific text, find again to identify files with bad permissions, etc.

I also discovered so. many. ways of having background processes running on a given Ubunut machine:

• Cron to launch jobs on schedule
• Incron to watch changes in files and launch jobs when they happen
• Tmux to keep jobs running in the background

I also learned that pstree can be a life saver when trying to identify the root process of a complex tree of subsystems.

Kafka

I've heard of Kafka several time, but always tought that:

• It was insanely complicated
• It was only for a few people doing super complex stuff

It ends up that both those ideas were false - while I would clearly not use Kafka without needs, used "by the book" it's not that complicated, and can solve a quite common problem: garanteeing good reception and processing of a message.

In the Shayp case it was about various IOT devices events, but it could be API calls or anything.

Combined with vendor hosting (Azure in this case), it means that even if your application is down (something that will happen), the event will still be in Kafka's queue, ready to be processed once your application will be back online - garanteeing "no data loss", something not that easy for a small startup.

(Much) more Python

This is probably the first year I wrote more Python than Ruby (on the server, as if I take everything into account, it's probably JavaScript that tops it all). 10 years ago I created a startup. We needed to pick a language and framework for the usual "web page facing database" kind of application.

We flipped a coin between Ruby on Rails and Python/Django (two solid options - at the time and now). I wonder how my career will have evolved should the coin had fallen on the Python side.

10 years later, I would probably have just picked Python. I did not change opinion about the language (I still love Ruby) - but Python popularity and the rise of data analytics made it a much more obvious choice today. I miss a bit of the fluency of Ruby, and some of the magic of Rails, but generally speaking I learned to like Python a lot, and I assume I'll use it more and more.

This year I used Python for web development (Django), web development (Flask), scrapping web pages (Beautiful Soup), process automation, data analysis (pandas and friends), and even a bit of machine learning (scikit-learn) and NLP (SpaCy, see below) - a testament to the language & ecosystem versatility.

NLP

The whole premise of newscheck was based on extracting article titles from websites and then identifying people names on them to finally make statistics on their gender. I had every piece but the "identifying people" working in my head before even starting:

• Create a small web app using Django
• Use a Django command to run the analysis
• Trigger the command every day using the Heroku scheduler
• Save results in a database

So my first prototype was just running a NER (named entity recognition) on the titles to see if I could get a good result. I don't know much about NLP, NER or related concepts - so I did some googling to find what people were using nowaday, and looks like it's SpaCy.

Once the model (different per language!) is loaded, SpaCy can be run in a couple of lines of code. I know the analysis could be much better, but it does the job for now and allowed me to go live.

Tools and Platforms

I followed the game rules as I restarted blogging and picked up a new platform. So I learned a new static site generator, Eleventy, and a new hosting/deployment platform, Netlify.

In both case, if you are familiar with that space (SSGs and PAASs respectively), switching is actually quite easy. I used Jekyll, Heroku and GitHub pages before, so the switch was not that hard.

While I've been working alone a lot this year, I still needed some basic CI/CD functionalities - and end up learning the minimum amount of GitHub actions. The tools generally works and if you are using GitHub anyway it means avoiding the "one more tool" issue.

On both personal (I want to keep things simple) and organisational (if I don't need to ask for more accesses/money, better), it's a significant edge.

Lastly, we did give part of the SkillsUnion courses using Code Sandbox - pretty much a VS Code and basic terminal running in the browser. Main reason was that it means we could start teaching (some) code without the students having to:

1. Learn Git
2. Install a lot of things

on day 1.

It does the job - but if I have to design such a course again, I'll get the minimal setup & Git on day one, and use the opportunity for the students to learn about Git & managing their own environment - something quite critical to a developer's job anyway.

Drupal

That one was challenging and interesting. I did some PHP code a good while ago, but I was not exactly prepared for Drupal. Lacking better words, Drupal is a whole ecosystem it itself - I can jump from Rails to Django or Laravel easily, because in the end they are using very similar concepts. Drupal is... different. Coming from a more "traidiotional" web development background, nothing made sense initally.

My goal was limited - create a small Drupal plugin to fetch data using an API and show them on the screen in a dedicated widget. The actual code part did not take me more than a couple of hours - but getting there was another matter entirely.

I was lucky to have support - from a colleague in the Drupal world since years, and from the Drupal slack that I heartily recommand.

Among others, somethings I had to wrap my head around:

• It's normal to checkout the whole Drupal project & make modifications where you need them (you can and should of course create your own modules, but the repo will still have every source line inside).
• Model wise, everything is a "Node" - a piece of content that has a type and can have quite different structures.
• Documentation is plentyfull, but difference between versions can bite you severaly - be careful to check the version of anything you read

Thanks to the support, this ended up going relatively fast (still needed a couple of days just to figure it out) - but I know I barely scratched the surface.

Nginx

So is the time for a confession - I generally despise/fear server admin stuff. When coding, if I make a mistake I can just fix it. Even if it's commited already, I can find the exact place back and do a PR. I also normally have a staging environment (and my local one). In other words - I've a lot of mecanisms in place to help me fix the inevitable mistakes.

I generally find system adminstration much less forgiving - a small error in a nginx or iptable config file can pretty much shut down your production, and not every action can be reversed. I think this is due to both the nature of the work and my lack of experience with it (at least compared to web development).

So my main coping strategy has been to find a way not to do that part of the job - either because there is a team/colleague in charge of it or (better) because we delegate that responsibility to a provider (I love heroku for that reason - I code my app, they manage the production).

As IOS Press one man development team, there is only me, and we can't use something like Heroku for various reasons, so I had to dig a bit more into system administration.

In order to get more reproductible configurations, I'm moving most things to Docker and Docker Compose (see below) - but I still needed some basic configuration. Having no real experience in either Nginx or Apache, I asked a more knowledgeable colleague what to pick and got as message "Nginx is slightly simpler to configure" - so I went for it.

All said and done - it's not that frightening, as long as I can test on something else than production. I did not need too much:

• Serving a single folder of static file
• Acting as a proxy to a Flask app for some more dynamic content
• SSL certification via Let's Encrypt and Certbot

Aside from losing two hours on a missing trailing slash for the Flask proxypass, this was relatively straightforward, with the whole config being less than 30 lines long.

I still prefer to rely on Heroku or a more knowledgeable colleague for this kind of tasks - but I'll clearly be less frightened the next time I've to do it.

Docker

Following the previous topic - I wanted to have reproductible configurations, and looks like docker is the way to go - it also meant I could test a lot of things locally and expect them to run mostly the same on the remote system.

I did not get into fancy stuff like Kubernetes (I deploy to a single server anyway) - just defined a Dockerfile per service, combined in a Docker Compose file for the whole stack. The general idea is that if an image exist, you can just use it (in this case you don't have a Dockerfile at all - just a reference to the image in the Docker Compose file), if it does not you can build it but you can also easily extend a given image - using it as a starting point for your own.

It is even possible to configure Nginx that way - using the base image and just putting your own configuration in.

It's not deployed yet - but feels promising.

Afterthoughts

To be very clear- I did not become an expert in any of those. I'm still a practioneer - I learn to be able to achieve my (customer's) goal - not to get complete knowledge about a topic.

I either have deepened my knowledge in areas I knew already (like React or Python) or I have learned something new (like Solid, Kafka, Docker, Nginx, Drupal, Netlify, etc.). For the latter it means I learned enough to do my job - sometime with help - and that next time I stumble on those topics, I'll be a bit less frightened (and a bit more efficient too).

Learning is still something I find a lot of personal satisfaction in - so I hope 2022 will be as good as 2021 in that regard.

I've been in position to give advice to early stage, usually non technical founder a significant number of time since my move in the startup world. One of the most frequent question I get is:

• What technology/language should I use for my web application?

The most correct and succint answer I got is from a colleague, Gilbert West:

• Short version: It does not matter
• Long version: It does not matter

Joke aside, the meaning here is that your company is not going to succeed or fail due to a (early) technology choice.

My own slightly longer (and less punchy) version is:

• Something your developer knows
• Something popular

Let's unpack those.

Something your developer knows

If we start working together on a webapp tomorrow, you probably want me to use something I've used in the past and that I'm confident with. Can I learn new tech? Of course! It's an integral part of the developer skill and I wrote about half a dozen of things I used last year for the first time - but there are costs there.

Using something new means obviously learning (something that takes time), probably being less efficient (more time) and probably making suboptimal choices (even more time). The main issue for me about developing a web application in let's say Express (a tech I'm a bit new to) versus in Rails (a tech I used for at least a dozen projects) is not really learning the language but the ecosystem.

Every technical framework comes with a (usually) large ecosystem of librairies (open source building blocks for standard functionalities) and practices developed along the years. The question are not really whether they are better or worse than others - it's just "the way we do things" in that specific technical area.

Those matters a lot. Going "against" the way a specific technology works is going to hurt. It's going to be uncessary complex and make the code much less readable by someone else.

Learning the ecosystem and practice take much more time than learning a language. To make things practical, if you ask me to manage authentification, upload images or manage an administration panel (all typical requirements of a web application), I directly know what to use for in Rails. In Express, I'll have to google. I'll find out eventually, but again - time.

Again, my example here between Express and Rails is purely based on my background - it would be the exact reverse situation for someone used to Express and having to use Rails for the first time.

In other words - you generally don't want to be my first project with a given technology.

Someting popular

This is linked to the first issue but different. As a business owner what you want on the technical side is security and room to grow - much more than for instance performance.

Security means that if your first developer leaves, someone else will be able to pick it from here. Room for growth means that when your business expands, you'll be able to hire more technical staff to work on it.

Both of those require the technology to be popular. Popular technology means:

• Developers available on the market
• Consultants with deep expertise
• Extensive documentation
• Blog posts, articles, etc
• A lot of questions and answers on Q/A sites like Stack Overflow

In other words, using popular technology means you'll never be alone. Regardless of how good they could be, niche technologies are always dangerous.

The next part here is that in fact, technology is generally "good enough"

Technology is good enough

"But Martin, what if doing my website in Java instead of PHP make it much better?"

It won't (and again you can switch the languages there, or add PHP, Ruby, JavaScript or any other there). The current state of art is that all major tech ecosystems are more than good enough for your needs. Anyone trying to say otherwise either has an agenda ("I don't want to work with tech X") or just never used different technology and still think he got "the good one". Those are red flags. Again, it's different to say "I could do your site in PHP, but I'm much more experienced in Ruby, so I'll be much faster" - this is not an opinion about the technology, it is a statement about a specific person's experience.

You can make a 10M$ business with Java, PHP, Python, Ruby, ... Actually, several people did.

You are not Google

Finally, you get the "but Google" argument - yes, Google need very specific technologies and langages and other stuff to manage their business. But you are not Google. You'll probably never be (and that's ok), and even so, Google did not starts the way it is today.

So, on the technical side, your business has nothing special - and this is good ! You can focus being different in your business, and just use boring technologies to make it happen.

Freelance

I'm a freelance those days, but this is the advice I give and practive. I develop applications with things like Python, Django and Postgresql - technologies that have been there for 10+ years, continuously improved, sustained by a healthy number of active developers. Mature, "boring" technologies that power the world and make things happen.

Someone inside BigCorp (which can be a private company but also a public one or a part of an institution, governement, etc - what matters is that it's big) Bob, a manager stumble into a massive inefficiency: team blue is considering building a task tracker (or an accounting software, or a security one, or whatever productivity tool is needed there - let's call this $SOFTWARE) - while team red already has one / is already building one.

Listening only to his courage and righteous fury facing this obvious misuse of company resources - building the same thing twice inside the same company ! - Bob quickly gets into team blue meeting:

• You don't need to build this - team red has one already, you can use theirs !
• But our needs are not the same - we're not sure what they are building is good for us ?
• No worries - my cursory look tells me you need the same thing - and I'll discuss with team red to make sure to take into account your needs

Being thorough, Bob also barges into team red meeting room:

• Good news! $SOFTWARE will also be used by team blue!
• But $SOFTWARE is just currently being built - and we have a long list of features that we need already
• It's ok - their needs are almost the same

His job done, Bob retire to his meditation room - and thus a F35 is born.

The F35

I'm no expert in weapons - but the story of the F35 as I understand it is mostly as follow. The US Military is made of several branches - Air Force, Army, Navy being the three biggest. Someone realized one day that if Air Force had planes (which make sense), the Navy also had planes - and so had the Army. Worse - all branches had different planes and were ordering them separately.

Thus came the logical idea - let's build a plane that is going to be able to fit the needs of everyone - so the whole US Military could use the same.

What happened is a a very, very long process - as a plane able to fulfill all branches specification was something very complex (and let's face it, combat planes are not simple things already) - that means also very costly, that finally gave birth to a plane that was:

• Less good in dogfights than the FA/18 (The Air Force current fighter)
• Less good to kill thanks than the A10 (The Army tank killer fighter)
• Not really good at landing on a boat (something the Navy cares about)

Ie - while being widely more expensive, it was actually worse than every plane it wanted to replace.

This in turn led to the miliarty produce "versions" of the F35 - specialized for a role or another one - again on a very inflated budget.

In other words - the plane for everyone ended up being a costly thing no one really wanted (they got it anyway, and us too in Europe, but still).

The F35 Fallacy

There are several fallacies at play here:

• Duplication are inherently evil
• Grouping effort will lead to a better/more efficient software

This misjudge a lot of context - especially in big companies.

If it looks the same it is the same

Most task tracking software looks the same from afar - until you get into the details. Maybe team red uses very specific tasks but with no order (they operate in an area with strong autonomy) - while team blue needs to respect very specific processes. Maybe team red love transparency and boards where everything can be seen by everyone while team blue is actually in HR and require strict permissions.

Adding some simple features won't hurt

So we have different needs - it's ok, we can add those to the software - the core is the same, it should not impact it much. Except most software tend to be late already (and overbudget, but let's focus on what impact our users). Adding "one more thing" especially when not taken into account from the start may actually delay it significaantly - to the furor of team red users that were promised it and are now facing delays for reasons completly unrelated to their needs.

Delays will come from the development time - but also from additionnal test needed, maybe integrations, etc.

The software will be better for everyone in the end

Finally the software will be "done" (as much as a software ever is, but let put that part aside too). At least it will be better for everyone. Except it most probably won't - cramming the features means some will be "in the face" of users that don't need them. Or (as the F35) it will be generic and hence require a huge level of customization by each team to adjust the way it work to the way they work.

Use cases that were supposed to be "simple" will turn into multi-screen wizards or dashboards with dozens of levers and gears to manage to get a result.

And they were happy ever after

Assuming the software somehow manages to get out - then there is the rest of its life - with probably competing use cases or priorities at every corner.

Results

The result of this "cost efficient" approach is probably going to be a massive spend, large delays and worse of all - furious users.

Some lessons

The general lessons here are:

• Things that looks the same are not always the same - so in doubt, look closer. The devil tends to be in the details
• Disturbing one audience for the sake of another will probably not end well - make sure everyone is indeed better with the deal, and evaluate planning impacts
• Small, targeted software have a far better chance to be useful (and hence - used) to their intended audience than large generic ones.
• (apparent) Duplication may not be the end of the world. If the cases are indeed close enough, maybe some integration can progressively be built to ensure interop - until maybe the use case can be merged down the line ?

Next time you feel that people are duplicating work - make sure it is the case and that the duplication is actually hurting - you'll realize that autonomy may be a bigger benefit than normalisation or cost cutting.

This is a bunch of experience, lesson learned and some insights about whether you may want to take the status or not. A part of it may be Belgian specific (I don't know the details of other job markets).

History

I pretty much got a freelance status when I cofounded Pull Review years ago - you can't be an employee of a company you own, as being an employee in Belgium implies some kind of subordination. When I decided to leave it, I just kept it (I had done the paperwork anyway) and I was getting a kid so my work life was a mess anyway.

Except for those few months, I was always a "fake freelance" - ie working mostly for a single customer at the time, and being treated like any team member. I actually did five years at Bluesquare (including 4 as CTO) under the status, without anyone batting an eye.

Last year

I left Bluesquare a bit more than a year ago, with the intention to get back on the market as a senior developer. My "plan" (as much as it exist) was to find a company I wanted to help, settle with a team and stay a while. That's not exactly what happened (see the details of my 2021 year) but this was one of my best year.

The pro and the cons

So let's see the good & the bad of the status.

Pros

Money

Let's start by putting this aside. The money is stupidly good. There is a "market premium" on consultants versus employees in Belgium. I'm not sure it's fair, I can't really explain it, but it's there. I'd say it's around 30% so it is clearly significant.

The theory is that it's the price for the increased risk of being fired (as a freelance, your contract with a company is a service one - which means it's much easier to break - even if nothing prevent to have notice clause in freelance contract - I've one in mines). The reality in this industry (and at a decent seniority level) is that it's a negligible risk as companies have much more trouble finding developers than the other way around. It does not means you can't get fired - just that "finding a job that pay decenly" is not going to take a lot of time.

So that's a pro. And yes, it may be enough. Getting more money can go a long way toward living the way you want - whether it's about holidays, money to sustain your family or being able to put money aside for a house or a break. Don't let anyone say otherwise (people that says money does not matter generally have a significant amount of it).

Variety

Being able to work for different clients (possibly at the same time with multiple part time) is really nice. While you can learn a lot inside a given team/company (especially when the company itself is evolving), there is no doubt that seeing different companies allow you to learn a lot - it's all about context:

• Technology is different
• Teams are not organized in the same way
• People are just not the same

Each of those means an initial cost to learn - but also benefits to learn. On the company side, you can bring your various experiences and hence a lot of different perspectives.

Side contracts

Another benefit is how easy it is to get paid for some very small amount of works. Two example I have to mention:

• Mentoring: Whether people or compaanies, it's generally very small amount of work (like a couple of hours per month).
• Teaching: I love teaching and again, the status allow to just bill some hours/days there

While even a full time employee would have the time to do this the problem is that the status does not allow them to be paid for any work outside of their job.

Work life

A surprising benefit I found is more linked to my place in the companies I'm working with. As a freelance, even full time, the relation feels much simpler. They pay me money and I deliver some value. Pretty much everything else is irrelevant, and this include for example any kind of career management.

This means no evaluation, no KPI, no big meeting about how the promotion system works, etc. Having spent some time on those, I realise I really like being able to focus on the work - this does not means "spending time alone coding" - it includes team relations and projects, I just get much less of the "HR theater" - and it's a relief.

Cons

Admin and costs

Being a freelance in Belgium pretty much means being a "one person company". While a status of "natural person freelance" ("indépendant personne physique") exists, you have fiscal reasons to get out of it once you reach around 50k€ of yearly turnover - something that is very easy as a developer.

So you have to create a company, and this come with complexities and costs.

• Complexities being paperwork. You need to invoice (no more "pay coming by itself"), make a VAT declaration every quarter, keep track of every expenses, etc.
• Costs is mostly an accountant. Why it's probably possible to work without one (or with limited help), the ratio between cost and benefit is just too good - but that's still around 2k€ a year.

Some days I think 50% of why I'm paying my accountant is to remind me of my administrative obligations (I'm quite bad at discipline).

No work no pay

The employee status in Belgium is pretty good - especially when shit happens. I took pretty much a half time when my first kid was born. As a freelance this meant cutting my pay in half during that period - while as an employee I would have benefitted from various helps.

This is something to keep in mind - being sick, having to support a family member or having small kids as a freelance create some clear financial risks.

First to leave

Despite what I said about job market, as a freelance you are usually both expensive and easy to let go. That would put you in the spot of the "first person to let go once cash flow is low".

Summary

Despite the cons, I'm more and more convinced I'll keep the status whatever happens. Being outside of (most) office politics and the possibility to do small paying jobs are two things I'm less and less ready to let go.

That was brutal - but not without ground.

Even worse - it's something I've been thinking/saying more time than I'm confortable to admit. Let's be honest, how many time were you handled a project/code base and though "Waw that's super great, I'm really thankful to whoever did this!" - probably much less than the number of times you though "What a mess" or "why would anyone do that this way?".

About the job

Aside from all the problems of style and taste, I think some root cause here is based on an incredible fallacy of our industry that most of us have internalized to the point of not even putting it in question - that is, that our job is about producing good or even great code.

The reality is - we're not paid to make the best available software. We're paid to do a reasonably working software in a reasonable amount of time for a reasonable amount of money.

It's something that I've been at peace with since years already - mostly because it's the only logical way of operating for the company. Regardless of the profit/non profit status, it's all about economics - ie producing value fast and regularly enough. Both aspects are important - this is not a plead for dirty work, it's that code is just a means to an end that happens inside economic constraints (time, money).

Judging intentions versus acts

Another way to look at that is the usual "We judge ourselves by our intentions and others by their acts" - or in this case, their code. What we usually miss in those situations are the conditions in which that "bad" code was created. Maybe the programmmer was young and inexperienced? Maybe they were new to that technology/context? Maybe they were just given three days to make it work and promised themselves they would clean it after - before being sucked in another emergency?

We've all produced code under less-than-stellar circumstances - and we would clearly invoke them in our defense should that code be challenged "Yeah, I know, this was done in a single evening after a sleepless night with my sick kid while requirements where changing on a daily basis". Heck, I coded a full prototype "between diapers changes" a while ago.

Understanding

This is going to happen again - and remember that you are someone's else previous guy. So let's start showing some empathy and understanding to that person - even if we don't know them at all.

Most of us want to do a decent job - that's probably what the previous guy wanted to do too.

A middle manager at a company I was discussing with was explaining their intentions regarding their team. Among other objectives was to increase coaching done by senior people in the team and to get the team on some kind of task tracking tool.

They went with those proposals to their boss, that approved the coaching part but wanted to wait for the task tracking part, to the middle manager desmise - the two proposals were complementary and it's not like one was going to prevent the other to happen.

I asked "Why didn't you do it anywway - it's your team, and it looks like it makes sense". I generally try to get my management support, but some decisions can just be taken with the team, even without top management official approval.

Their answer was simple: "I can't buy the tracking tool, I need approval for the expense".

To give the full context - we're talking about a team of 10+ people and a software costing less than 100€ per month.

The problem

Someone responsible for 10 people, so for expenses probably around at least 50 000€ per month could not put 100€ in expenses without an explicit approval. They did not have access to a company credit card, so they could not move forward without the approval.

The situation above is one I've seen a lot of time - it's far from being unusual. What I realise is that it makes for a very simple autonomy test.

The test

"What's the amount that you can spend without having to ask anyone for anything?"

Someone around me noted that this could also be asked for team members, not only middle managers - if you decide to spend 5000€ or more on someone, surely they could be trusted with using let's say 100€ per month without having to do paperwork?

I'm not advocating for people to have this to buy lunch (even if for a team that could again make sense), and I assume that the expense will need to be justified (with the receipt put in the system, etc).

If someone abuse it, they won't have a second opportunity to do so - and we're talking super small amounts anyway.

This is something I intend to ask in interviews from now on. As any question with a simple answer (a number) it does not cover the whole range of what team autonomy is - but it looks like a good place to start to measure autonomy and trust.

If you read this, can you answer the question on Twitter about your team? I'd be intersted in the answers.

Software development is full of uncertainties. Most teams I've been part of generally start development with little-known facts and a lot of unknown ones - both on the business and on the technical side, from what we should exactly deliver to how we should do it.

The summary of that is: "We can't do X yet, we need to talk about it before"

My experience is exactly the opposite - ie that generally we need to do it to be able to talk about it.

This is in a way another side to the Delaying decisions post I made a long while ago.

Working with uncertainty

The reason talking may not solve the problem is linked to two unsaid assumptions:

• That talking can indeed clarify the problem - either because someone has some information that the rest of the group does not or because talking will make better solution/clarity emerge from the existing amount of knowledge
• That "going in" without this crucial step will be costly or cause irreparable damage to the team/project/company

Those are generally untrue. Of course, if a stakeholder has a lot of information that has not been shared, it needs to be, but in all but the most dysfunctional teams, the information is shared - at least to a reasonable extent. That includes typically the root user problem.

Once the knowledge in the group is mostly equivalent, talking about it (solutions and way of working) has a sort of diminishing return - there is only so much you can do in the abstract.

Trying things, even with high uncertainty is generally not that costly - you can draw some mockups to see how a feature could work, or even put some code to evaluate a solution's actual complexity - without incurring heavy costs or unchangeable decisions.

The learning and the end result

Even if the code/mockups/whatever artifact produced had to go directly to the trash (sometimes it has to), it generally produces much more knowledge than the starting discussion - and probably much faster.

That is often a good time for that discussion to happen - as it can now start on an actual work in progress instead on an abstract idea.

I've seen a lot of heated debates dying down directly as the solution become obvious (or obviously bad!) to everyone when facing some concrete result.

Software development is not physics - but being confronted to the hard reality generally makes a lot of theoretical options die, making decisions much easier.

Let's reality solve the debate

I've seen more and more than even as a manager (where I do have the decision power) I was better to let ideas/proposals be tried than to talk about them. This is true about code, but also about things like organization - it's often complicated to evaluate how a new process would work or help - so if the proposal is not too big/complex my default answer became "let's try it for two weeks - then we'll evaluate".

Things that work tend to become obvious in days - things that don't die by themselves well before the due date. In addition to being cheaper/faster, it tends to avoid a lot of ego-related issues - as suddenly it's no more about who's the most confident or loudest or fastest talking person.

I've won a lot of time and sanity (due to less debate) by cutting discussions short with "Sacha is going to make a first attempt at it, we'll discuss once she has a first working prototype".

A few months ago I blogged about how networking matters - this post could be named "Networking matters, again".

My previous post on this topic was about how much a good network could do to land a good job - but I started to realize I only taught half the story. Sure, my network was a great help to land my job - but it's as useful or even more once I start working.

The one-man product team

My current position could be summarized as a "one-man product team" - in short, I'm doing the whole process from collecting requirements to maintaining the software (and everything in between - mockups, design, development, deployment, etc - this will get its post in the future).

While I love the freedom and the challenge, it's also a lonely job - especially on the tech side. I got a good amount of experience, but it does not replace a second opinion or a second pair of eyes.

Enter the 50 colleagues

The thing is - I'm not alone. Through several missions, jobs, meetings or others trainings I've probably been in contact with 50 (maybe 100, I don't count) other developers of various specialties and skills level. Through LinkedIn, Twitter, various slack accounts and other channels, I'm still able to reach them.

This is something I still do, if not daily at least weekly, generally to "fast track" my entry on a new topics. Programming is wonderful in terms of resources available (documentation, blog posts, tutorials, etc) - but nothing replaces a 30 minutes exchange with someone who already went through the same problem.

That's where that you'll get the "I would not do that if I were you", "This is the way it is in the doc, but the reality is not the same" or "Be careful of that specific area it's much more complex than it looks" or even "There is another option there you may want to consider".

Looking back to the last period I did that for:

• Where to go for multi-platform mobile development in 2022 (thanks Martin)
• Knowing options about Odoo custom development (thanks Sébastien)
• Get feedback on Wallonia subsidies rules (thanks David)

What you are getting

This means that hiring me is not just hiring me - you are also hiring my network. I may be the only developer in your company, but I have access to a lot of other developers.

This is pretty much part of my offer as a "one-man product team".

The term “quiet quitting” refers to employees who put no more effort into their jobs than absolutely necessary. They don’t volunteer for extra work, and they don’t put in extra hours. They just do the bare minimum to get by.

The wording is an impressive combination of insult and bias while being extremely loaded.

This is related to the kind of wording you find in job offers "We look for someone that goes 'above and beyond'". It's a nice way to say "We look for someone that will put in extra hours" or other kinds of "extra" work - without corresponding additional compensation or benefits.

This is already bad enough (it should be taken as a red flag for anyone looking for work), but the "quiet quitting" expression is even worse.

"Not putting more effort than necessary" is called "working" - not "quiet quitting" or anything stupid like that. Same about "not putting in extra hours" or other things like that. A work relationship is a contract where the employer pays for a certain amount of work - not more, not less. Should the employer wants more - well they can enter a negotiation, which means bringing something to the table.

So - next time your employer asks about "going above and beyond", ask them what -they- are going to do to go above and beyond your compensation. Why should one party do more than the other? It's a contract, not a charity.

So - give me a break with this BS.

In the end, work relationships tend to be a leverage game. Contracts can only do so much - if an employee has no money reserve and is in no situation to find another job (easily), they'll tend to do whatever is needed to keep the job - whether fair or not.

This can happen on the other side too. In a market where a lot of companies are looking for a specific kind of talent (looking at you, software developers) the leverage is on the worker side - and it can also be abused.

• "One man product team" - joining a company either at the very start or at the start of their software development, with a job that is a combination of product owner and lead (solo) dev.
• "Techical Team Leader" - I make a difference between that role and something like "manager" as team lead implies that you work with your team, they are not just working for you. In my case, than means coding/doing technical stuff.

The fun thing is that those jobs are by nature ephemeral.

It can go two ways.

As a "one man product" team, either the project fails to find it's market/revenue - and then it stops and I leave - or it start getting traction, and it means we're going to hire some help, moving the job in the second category "Technical Team Lead".

As a "tech team lead", it's pretty much the same - if things go badly, well the team will shrink (back to "one man product team") or the project will stop. If it works, we'll hire more, and at some point the job will move more and more toward management.

The inevitable path

I've been there before, several times. I like to think of myself as a reasonably good developer (I know people much better than me, but I've no imposter syndrom either - I've seen I can provide good value there) - but as the team go from one to three then five then eight, the difference I make with my coding capabililty is going to shrink. I may represent 50% of the "firepower" in a team of two (more or less depending on the skills of the other person and how much time I spend on "non development activities") - but this will shrink to only 16% in a team of six.

Adding the fact that as a team lead, you have other tasks (product related, team related, documentation related or others), it's actually generally less than a simple porcentage of the team size.

Combine that to the fact that leading more people requires generally more time (at least if you care about the team - if not, well, find another job), the "good" path invariably lead to progessively dropping the "Tech" part.

I tend to see the inflexion point at around 5 people - more than that means you are leaving the coding space.

It does not means it's bad

Like, managing a team of developers as a 'former' developer is still both fun and useful to both the team and the company - it's just another job. If you have a team of 5 but that your own coding capabilities are still critical to the team/company success, you did something wrong:

• You did not hire good/senior enough people
• You did not share unique/specific knowledge you have
• You did not invest in your team capabilities

So at that point, a lot of other tasks/activities open about providing the context & clarity needed for the team to produce a maximum of value - and then leave them the space to do their job. Working on them will lead to much bigger results that working on your own technical skills.

The Last Feature

I've a mixed feeling about that transition. I love both sides of my job - that's why I select those kind of positions, so looking around and understanding it's time to transition comes with a bittersweet taste. It's generally a sign of success (bad products/businesses does not lead to bigger teams), but that comes at the cost of "letting go" things I really like - hence the ephemereal nature of the job.

As stated before, it's no more a new situation, with means I recognize it. Finishing a feature or the last fixes following a review and realizing "Well, this is probably my last feature".

What I'll call "development team lead" here is leading a relatively small (let say 2 to 8) developers in a position that is a mix between technical, people and product role.

Reading other people blogs, I'm always impressed by the amount of "programming principles" that people developed over the years that feels like they can apply everywhere - my own experience has been generally so mixed that there are very few (if anything) I would stick to on the technical side as in "apply everywhere every time".

What I did realize is that I do have some - on the team lead part. Nothing earth breaking, but things I've not seen applied that often so that are probably worth a post.

So, without further ado, here are my

Development Team Lead Principles

(in no specific order)

Delay decisions

Facing a choice or something to decide, whether it's a feature to pick or a design decision or an architectural choice, first ask yourself if this decision can wait.

Generally speaking, the more time pass, the more you know about your app, context, customer, etc, so the easiest it is to pick the "good" one. That means that waiting to decide / going for options that does not fork immediatly is generally a good idea.

I wrote a blog post about it a while ago.

The only people with a right to decide how to do something are the people doing it

That's a bit long but I could not make it shorter. The idea is that the group of people directly doing the work should decide how to do it. That does not means "only the developer doing it" but more "developers should decide how development is organized/done/etc". In other words: you don't get a vote if you are not part of the team doing the work.

That's not specific to development - I would not dare go to the sales team and tell them how they should work - I sure hope they know better than me.

That also means that if you manage a dev team without being actively coding yourself (or reviewing, or having some kind of stakes and knowledge there), I think you should leave technical decisions/organisation to your team (but nothing wrong in facilitating their process).

If it's not broken, don't fix it

This one come directly from Havelock Vetinari a fictional character created by Terry Pratchett who has it as a family motto.

My experience as a developer is that pretty much everything can be changed/improved - but generally should'nt. Fixing something that is not broken feels like a very very low impact activity, which means you have probably better things to do.

I love ideas - but I'll always ask "how will the customer (or us) benefit from that?". If there is no tangible answer, maybe we just need to leave it there and move toward more impactful activities.

Try trumps Talk

Facing decisions, either technical or process related, discussion about the benefits of one technology/library/process over another can quickly become tedious. My usual answer is if the change is not dangerous to simply try it for let's say two weeks (if it's a process) or on a branch/dedicated feature (if technical), then have a look together and decide.

The catch is that in the technical case, if the decision ends up not going that way we may have to throw away some code. That need to be clear from the start to not anger the colleague doing the trial.

My experience with this is that the "decision" phase become obvious extremely fast - benefits are more visible when doing it than in the abstract, and idea that looks good in theory but are cumbersome in practice will be easily discarded.

Long form writing is underused

We've all heard the "this meeting could have been an email". The easy answer is when information needs to be communicated to a group of people to just... write it down. In an email, a Slack message, a notion page - whatever. The meeting can still happen if it need to be discussed, but at least everyone will have the information.

This applies to a lot of other situations. I love chat (as in a immediate/short/non blocking way of communication), but long form with clear context is an extremely efficient and underused communication media.

As a tech lead it's one of my primary tool, and a reason our "team meetings" are generally not about me talking - if I have information to pass, I'll just write it down before.

Someone did something interesting? Write it down. A feature is more complex than it appears? Write it down. We need to decide between two options? Write them down.

Discuss and decide together

This is something I've evolved on. The more time pass, the less decisions I take "on my own" even when I do have the "right" to it (by seniority, rank or both). Writing about it, outlining options then discussing with the team should almost always lead to a better decision than the one I could take alone. It generates more perspectives, open options I did not know about or reasons not to use one I could not see.

This does not means it has to be a democracy - just that decisions are discussed together. In my experience, consensus often happens, and if not it generally means it's worth digging - maybe specific people will be impacted more than others? At the end, a decision needs to be taken and it can still be a dictatorial one - but it will be taken with much better context.

Boring is good

Technologically wise, going for mature, boring languages, frameworks, approaches is generally very good for the company. The underlying hypothesis is that your team is not facing a completly new technical problem or context - ie people have the same somewhere else. It's the case for 99% of the companies.

You want the business to be disruptive - not the technology.

Mature/boring tech works, has people mastering it you can hire, blog post and documentations you can read, stackoverflow answers on your problems, etc.

Most companies can succeed or fail with pretty much any language. The only mistake is to use something niche - even assuming the niche tech is better (it usually is not), it won't be worth the maintenance headache.

What is the job actually?

Management has evolved (or should). In teams like the one I have, what your job is'nt is pretty clear: your job is not to tell people what to do.

On what the job is I'll just refer to Claire Lew that wrote the most interesting things about leadership I ever read.

The part that stuck the most with me is "provide context and clarity".

• Provide context so that people can take good decisions, instead of telling them what to do (using context you don't provide)
• Provide clarity on the goals, priorities

"Ensure psychological safety" should be a prerequisite more than a goal, too.

Pitch

If this resonate with you, let me know. If your team can use some of that kind of advice, have a look at the services I offer.

As in: I'm active in technology but most of the issues and decisions are take are not technology driven - and I don't think they should.

We used to joke years ago with Gilbert West about our advice for people asking us "What language should I use" when starting a new business - the answer was pretty much "It does not matter".

I still believe in that (sort of), but I also think there is now (probably since a while) a "default" language - python.

Why

Basically it does everything well enough to be a "Swiss Knife":

• Want to do a web application? Django is a very solid, mature, rich ecosystem, battery included framework. It can pretty much support whatever you want, from full stack to just backend (thanks to Django Rest Framework) if you really want to have a React or other front end with it.
• Need to script/do some automation? Python is installed (or installable) pretty much everywhere, is easy/convenient to use as a scripting language
• Need data transformation or data science ? Python is one of the two languages with real ecosystems there (the other being R), and the only one which is also a "general purpose" language.

Basically - you can build 98% of the startups/companies with that. It's also widely used, good documentation, lots of developers to hire.

But you can use more than one language, right?

So, yes, but it come with a price - multiple ones actually:

• It makes your infrastructure more complex - even doing separate apps for front & back does. Suddenly you need two servers.
• Features are just longer: something that was some Python & a bit of HTML is now some Python API, then a client to parse it and show it using React
• Your team need either to all know both languages or you need to split them in separated teams, with the associated costs and coordinations headaches.

It's true of other languages

Honestly? No. The only one that come close to that is JavaScript. I don't think it's as productive on the backend (there is no direct equivalent to Django in JavaScript). It can work for mobile apps (using React Native), so that's a plus, but as a scripting or data language it's nowhere as good.

It's not about the language

As usual - there is nothing here that is specific to the language itself or its technical capacity - it's a combination of ecosystem, history and market share. You could argue that those are a result of the language capabilities - but that's just not true.

So if you ask me about languages or what to use for your startup - let's just use Python.

On the other side, companies tend to present themselves as "disruptive", "market leader", "world changing" or "future unicorn". Every job is to be taken at an "incredible" company, with "very competitive" salaries as a "unique opportunity".

I used to find that childish. I think it's actually harmful and that it needs to stop.

It's harmful to developers

Despite what some people seems to believe, development is not a gift given by god to the worthy nor an arcane knowledge requiring incredible and unique capabilities.

It's a skill set that can be learn and taught to pretty much any one (to certain degree - but that's true of all skills) - the same way you can learn to fix your bike. The outrageous salaries that we can get in the industry are not linked to any specific importance but to some very basic economics (ie: supply and demand).

By hyping us as "rockstars", the company is putting unreasonable expectations on the delivery - they want greater than life "heroes" able to "save the day" - which means than when they are going to get, "me", ie a human being with good and bad days, good and bad ideas and a capacity for mistakes, they are probably going to feel it does not fit the bill - no one does.

The "hero/rockstar" rhetoric has a second problematic side - it tells the story of individuals winning (or losing) on their own, removing any responsibilities from the system (ie: the company), how it is setup, etc.

Most bad development I've seen did happen under bad circumstances - from unclear or changing requirements to imposed deadlines to previous bad technical decisions. Pushing the "hero" narrative is starting a narrative of the employee having the full responsibility of the win or the fail (well, of the fail at least).

So: development is a skill, and being a developer is... a job. You know, like other people are postmen or truck drivers or finance analysts.

It's harmful to companies

Positioning every company as "disruptive" or "future unicorn" (saw that on actual job postings, I'm not joking - I wish I was, but I'm not) is also putting unreasonable expectations - there on the candidate side. This would mean a real unique place of work, plenty of growth opportunities (after all you are going to grow a lot, right?) and Google like salaries & perks (right?).

Most companies are not offering anything like that - this message is a combination of basic boasting, lame attempts at showing themselves as different (by saying what every other company is saying) and possibly preparing staff for the "hard work" needed for such a spaceship.

This will inevitably lead to employee insatisfaction, which itself will lead to people leaving (if/when they can) or doing the bare minimum.

So: your company will probably not "disrupt" the world nor being the "next Google". It's just a company. Hopefully it do sell enough so that it can pay its employees. That's a already a nice success.

Let's get back to earth - it's not that bad down here

I'm no rockstar - I'm a guy doing programming as I generally like it and making it my job as it put food on the table. I try to do my job the best I can, knowing I have good and bad days, tasks that I love and others I dislike and so on.

Your company is not Google (Google is not that great for all people anyway) - you are a profit driven structure trying to get enough money to live and maybe even expand at some time, hopefully without killing your employees.

You don't offer me an "incredible opportunity" - you propose to pay for my time and skills for a while. If things go well, we may make a bit of a journey together, I may grow in skills, responsibilities and salary and you may get more value from me.

That's a less fancy story, but a more honest one.

You and me are not that "special" - and that's ok.

To be honest, in an industry that "seniorize" people after 5 years, I probably deserve something more akin to "Ancient Developer".

When I left my C-level position 2 years ago, I had one certainty - that I needed to get off a pure management role, at least for a while, and a lot of uncertainties - notably about my capacity to make a difference and to convince a company to go with someone like me versus a 28-year old senior.

I guess I did got some answers that lead me to review a bit what seniority means for me those days - both from my point of view and those of my customers/employers.

Seniority as in Fitting In

Maybe the first thing is that I expect to "fit in" in the environment, not the other way around. I'll probably have opinions about how the company, team, code is organized, but my first approach is always to fit in, assuming that things I find weird or outright bad probably have some reasons to be that way - they usually do.

That means among other using the technology that's there (even if I would prefer/recommend another), taking tasks in spaces that are mostly unoccupied, following the current process (if there is one).

Time for challenging things always come, but there are good reasons to not start with that:

• I need time to learn how and why things works the way they do. Most companies are there since a while - that means whatever way they work allowed them to survive until now.
• I need to earn credit (with the team and the management) to be in a position to be listened to when I'll propose something. Going to fast (even being right) means a good chance of burning both the opportunity for improvement and the relation.

This is I think a reasonable expectation to have for a Senior Developer - having seen multiple companies & teams, you know things can work in many different ways.

Seniority as in Product Engineer

Working in small companies or teams means that my role is often not purely technical. Most "technical" problems aren't, so a significant part of the work is about talking & understanding stakeholders need - generally customers or management or both.

(non technical) Management is often used to have trouble communicating with the technical team - in both directions:

• They struggle to convey their priorities and needs
• They struggle to send proper and actionable feedback

This generate frustrations on both sides - I've often heard "Management does not understand this".

I see development as a support (if often strategic) function as it generally takes its marching orders and information from somewhere else (sales, management, subject matter experts). We generally don't define the "what" - we manage the "how".

A bit part of my job is often to help management & development to align - first on my own work, then often more generally in the company. Being someone that "speaks both languages" is generally of tremendous help.

Most inefficiencies I've seen in development are about building the wrong thing - not the thing wrong.

Something that baffle me to this days is how many developers seems reluctant to engage on this topic - including those that will in the end complain about "having to do things again".

Seniority as Finding where my value is

As I'm generally hired by the management (sometime technical, often not or not anymore) a key point is generally to find where I can provide the most value. Sometime it's getting a huge refactor done, sometime it's about getting some features out or stabilize the platform or improve the team or anything else.

The key point is that more often than not the reason invoked for getting me in is not going to be where most value can be generated - which means it's up to me to find that spot, do the job then report. It does not means not doing something I am specifically asked to do, but a recognition that I may be in a better spot to judge where I can produce value than the person paying my bills.

Seniority as Managing your Manager

I've been a team lead (I'm one again, I guess) and a C-level. Having "fled" the position does not means I forgot about what it is about. This is generally very helpful in my interactions with my own management. Being able to tell your boss "I understand" (truthfully, of course) goes often a long way.

This do not means "I agree" - just that I generally understand their positions, trade offs and others. I know why they're getting nervous, I often understand why things start to become "urgent" from their point of view - so I can generally anticipate them or ask for information sometime before they think to provide it.

This falls under "Managing your Manager" - something that starts with remembering that they are a human being too. Being senior, often a freelance in a good market tends to put a less asymmetric relationship - while I do work for them, I can generally speak my mind, devoid of most games.

Seniority as Helping other Developers

Part of the "I'll create my work where there are the most obvious empty spaces" is to tell but mostly show to colleagues that I'm here to help - and that starts with them. This is something that has more benefits that I can count:

• It helps me build the credit I'll need to propose changes
• It improves my own understanding of the system (the software, but also the team)
• If the team is larger than three people and more junior than me, it's probably the biggest value producing activity I can do.

It's "working on the team working on the software" vs "working on the software" - or generally "and" more than "vs" as to work efficiently with the people you need an understanding of the software.

It's also a way to start a culture of helping each other in company missing one - quite often it just needs someone to start it.

Seniority as "We're going to regret that"

This is about facing relatively big decisions - choice of framework, big refactoring or stuff like that. It's about trying to project how much we are going to like or hate that choice in a year or two. Not in an abstract way like "this code is so beautiful" but in a nitty gritty way like "this make it difficult to debug" (or to test, or to change).

Some things looks very smart in the moment, and are disatrous long term. Part of the job is to be able to differentiate them with more than 50% success.

Seniority as YAGNI (You Are not Going to Need it)

Linked but not the same is tha capacity to say "YAGNI" to some proposals, generally starting with "what if" or some hypothetical. The problem with the future is that it tends to be different from the idea we had of it. That's especially true of startup's code as you are sitting on top of two hypothesis: that the code needs are going to stay the same and that the business is going to.

There is the usual: keep it as simple as possible, assume you can't know the future. I'm an economist by training - our motto is "Predictions are complicated, especially when they are about the future".

But what about the technology?

I guess you can be very senior in technology too.

As far as I'm concerned, I've seen 28 years old developers I would not beat in a hackathon/tech competition settings.

Thing is - that's generally not what work looks like. Work is full of those gray areas, human aspects, incomplete information settings and so on. Seniority for me has always been about having seen a good amount of different environments and managing those areas more than being the most knowledgeable person on a specific technical subject.

Again - software is not about technology - it's about the value it generates.

Bad rep

Internet seems to pretty much agree with the point, with a lot of advice on "how to explain short employment stints" - as if those were something shameful to hide or disguise.

As an aside, no one is telling companies that short employments stints reflect badly on them - it's the usual asymmetry where things that are ok for companies are not ok for candidates - anyway.

The idea from the company/recruiters is that not staying "long enough" at a company make you unreliable.

Meanwhile

I've left my last "long stint" almost three years ago now. During my five years at Bluesquare I barely did anything else - something I felt "came with the job" - I thought that as a CTO you should not have time for much else, and I was feeling overwhelmed most of the time anyway.

Since that time I did only part time missions, most of them shorter than a year - and I think I provided value in pretty much every single one.

What changed

Most of the change is actually the mindset - that it's indeed possible to bring value even before understanding the whole context. Working in small(-ish) companies certainly helps in that regard, as is scoping the work to avoid having to understand everything.

I also saw (in colleague, in me) something impressive changes happening in just a few months - sometimes a few weeks. My current team is in place since just 6 months (less for some people), something I've have trouble believing when I see how far we've got already and how well we function as a team.

On my own side it's about getting value faster, generally thanks to experience - especially the "fitting in" & "finding my value" parts. Having generally very broad goals helps finding areas of quick improvements in the middle of more long terms goals.

As a single developer turned team lead turned CTO in less than a year, I also discovered that you can lead a team as a part time job. It's not a given but good hiring and a led back approach brought a situation that's beneficial to everyone - the company, the team and myself.

Added bonus

A last but important consequence of those part time/short stints is how it make evolve my own relation to work. I've always been quite driven work-wise (and I still am) but splitting my time around different customers and moving on allowed me to separate a bit my value from my (current) job.

In other words, my career/work is "me" - it's not the company I'm working for at any current time. That means understanding that every job/mission is temporary - but they are and assuming the opposite is actually the "weird" opinion.

I've come to talk about my work as my current job - which is a way to express it's not going to last eternally - and that's ok.

Well, that was a fun year again - and now that I look back, quite a busy one.

Missions

I spent more than 90% of my time at my two main customers - Beeodiversity & Farm For Good, but I'm happy to have been able to add a couple of small missions on the side.

Beeodiversity

I work for Beeodiversity since almost two years now. In that time we moved from an idea to a prototype to (thanks to some EU based funding) building a team of 6 and releasing a first version and making our first sales.

That's work I'm quite proud of as really getting from 0 to 1, with all the logical evolutions - making just the software needed for a first demo, then making it better, then rebuilding it with a team to move it toward a sustainable product.

Being "CTO" or "Lead Dev" there allows me to use the full range of my "specialist in nothing" profile - talking with stakeholders (internal or external), helping with the strategy, building a software then a team and shaping it to a working delivery system.

It's just the start - but we've come a long way already.

Farm For Good

This marks my one year at Farm For Good - probably my most "unexpected" job (I did not have "A cooperative of farmers active in agroecology" in my bingo card of possible companies to work for). Here it's about taking a set of practices (and excel files) and organise it into a working software.

Most of the complexity is in the relation with the subject matter experts (here agronomists) and tryig to find a middle ground between the amount of data we want to collect (as it means form to fill for humans) and the insights we can to get out of it, in an area where quantitative/data based approaches are still rare.

While I'm a bit "on the side" of the main activities there due to not being often at the HQ and being part time, it's interesting to see the organisation growing and getting more and more ambitious - an ambition that software is going to contribute to fuel in the next year.

Ville sans nom

This is the typical "unexpected small project" - creating a small application allowing French author Alexis Briatta to publish stories about a mysterious city and the people that live there.

This is a nice case of helping a customer to shape their project in a way that minimize the time needed to build it - and hence the cost.

Having delivered a small but fonctionnal web application in less than three days of work was very satisfying in that regard.

Tapio

I had the chance to get back at Tapio for a very small mission helping a transition to a new CTO - being able to provide insight as an extern person with a good knowledge of the company and also of what the job requires.

Sign How

I worked a few weeks with Sophie and the nice team at SignHow - a community dedicated to collect Auslan (Australian Sign Language) signs in the form of short videos - pretty much making a dictionary of signs in video form.

While I'm no expert in accessibility, helping initiatives that make the world more accessible and inclusive for various groups is always really nice.

In terms of challenges, it was again about being able to dig in an existing system, learn enough about it to be able to deliver a critical feature (a payment system) in the relatively short time allowed before an important event.

It's also the first time I worked based on very precise designs thanks to Nikhil Bora - an experience I'd be happy to repeat.

Better Business

The year finished with another "old" contact as Eliane & Geoffroy from BetterBusiness reached to me for advice as their sustainability business moves toward a product centric one.

Learnings

Three years after my last full time job long run at Bluesquare it was again a good year in terms of learning - in skills but also in what I want for my own career.

Part time CTO works

What started as a mission to create and test a first prototype at Beeodiversity turned out in a full fledged CTO position, including hiring 5 people in 6 months, contacts with external stakeholders, various technical/marketing mix and taking over the software used to deliver the consulting reports.

While that was clearly not the initial deal I think I can say it turned out well both for me and for the company - despite being there half time. I did not see CTO as a "part time job", but I need to acknowledge that given the proper circumstances it can work - in this case aiming for senior people when hiring, opting for a "light touch" management style, keeping mandatory meetings to a minimum and a harsh focus on what is needed for the team to go forward.

An ode to the early stage

Linked to that experience & a couple of other, I'm still a very big fan of the "early stage" - whether it's new companies or new teams, I feel I'm providing my best value in yet undefined environments.

While I of course do work better with more information, I'm used to navigate in environments of unkwowns, making decisions while not having all the cards in hand and drafting a path that allow the organisation to learn.

As a candidate once told me about a former job "Everything was to be done, it was my best job" - I tend to thrive in those environments.

Building teams is fun

While I favor boring, mature technologies, something that's never boring or even the same are teams. Groups of people tend to behave very differently from one to another, and you get a new team each time you hire a new person in an existing one.

Nudging a team to find better ways to work together is a very satisfying experience.

The value I bring

Moving back to software development was a bit of a gamble - I'm experienced but also generally more expensive than younger people, and while that difference is "easy" to swallow when I apply as CTO, it's more complex once I position myself as a "Senior Developer".

I asked a couple of customers "why me" - what I got from their words is that they get a combination of skills that are generally complicated to find in a single person.

Pretty much:

• I can talk to (non technical) stakholders and convert business ideas into software products
• I can code a web application - by myself if necessary
• I can hire and lead a team

More specifically I got credits for:

• Saying my opinion "without any concern for your position" - generally challenging customers about making a software at all - something that would lead to my immediate termination. While a good market make this position not as dangerous as it seems, it's more for me a question professional ethics - I don't want to work for something useless, even if I'm (well) paid for it.
• Most people applying for "CTO" position tend to be able to lead a team or code - never both. I'm still a bit suprised about that one (like "non coding CTO" is a very weird position), going to dedicate a post to it as "it's complicated".

So in the end it's all about linking technical actvities to business value - in other words, as I told a colleague a while ago "If you don't see how the feature you are coding contribute to the company business, lift your hands from the keyboard and come talk".

Technology

This was not a tech-heavy year for me. Some quick pieces:

• Front end: I'm slowly and sort of reluctantly moving to TypeScript (notably thanks to Shad beautiful component library). TypeScript has always been a tech I thought I should like but don't use. I'm using it a bit, and while it's infuriating in its own way, I guess I'm going to continue using it. Best part if that you can really decide how much you want to use it.
• Firebase: React + Components + Firebase make a good way to start an app - with firebase being able to manage the authentification and a database (sort of).
• Back to the monolith: I was triggered by a tweet with something like "Front End frameworks were invented so startups could justify paying two devs for the job of one". While I think it's slightly aggressive, it forced me to ask myself "what to I win here having this separated front end versus just using templates (in Django/Rails/whatever)". The answer is not always as easy as I'd like, so I may be "back to the monolith" for new projects. My main concern is the absence of component libraries outside of React and the likes of it. This leads me to:
• Inertia: Inertia feels everything I want - a protocol linking a Laravel/Django/Rails to pages done in React where I can use components. Except that (at least in Django) I could not even manage the setup. I still think it may be the best of both worlds. If it works, which it does not.

This is still the year of just use Python

Evolutions

There was some changees of new realizations too.

There is nothing outside of the 40 hours

I spoke of Alexis's nice project. What I did not tell is that to deliver those three (3) days of work I needed almost six (6) months (!). This is not something I'm proud of (and I'm very thankful to Alexis for his understanding) - but it was a valuable learning that I can't expect myself to work anytime outside of the 40 weekly hours.

Maybe I'm older and more easily tired. Maybe I've kids now and more things to do. Maybe I progressively lack the will to force me to work again at 8PM once the house is quiet.

Whatever the reason, my goals to work on more different, smaller projects required to make time during my normal work week - something that's now done.

Can be committed without being eaten

I am and always was quite committed to my jobs - but leaving Bluesquare I also decided that I would not let one eat me again. What I was a bit worried about was wheter it was possible to not be eaten by the job while still feeling engaged by it.

My current answer is a resounding yes - as I have been pretty committed to Beeodiversity & Farm For Good (and other) successes. Being active on several projects certainly helps there, but I like to think I also managed to change slightly my frame of mind on this topic.

Bring value at different places

I used to think I needed time and long investment to provide value - which means staying at the same company/employers for a while. I've seen enough results of my work at different places to realize this does not have to be true - and that generating value at mutliple places is very rewarding - so I'm going to continue doing that.

Conclusion

I intended to move on to 2024 - but this has been long enough already, so it will be for another day.

This has been a very fulfilling year - and I've good expectations for 2024.

Process

Write your hiring process down, and communicate it (as much as possible) with the candidate, already in the offer if possible. Name the steps, the people involved.

Give as many information as you can in the job posting - about the tech but also about the team (how many people? seniority?) and the product (what is it? what phase are you on?). Be clear and upfront about the remote status (none/hybrid/full remote)

My current one is generally a variation of:

Job posting

As outlined above, I try to be complete there - notably I mention who is in the team and our product phase.

I still ask for both a resume & a motivation letter - I like to understand why people apply (aside from "I want money to eat" which is completly ok)

I try to spread it broadly - linked in, company site, network, job boards if it means I can reach people I cannot.

Resume based selection

I take the applications and (if I get enough of them - it's not always the case) I filter them to keep around 5 - less is missing opportunities, more takes too much time to interview.

Interview 1

Who? Candidate, Me

• Me: explain the company, demo the product, describe the team
• Them: voiceover on their journey, reasons they want to join
• I try to select around 3 people out of this phase

Interview 2

Who? Candidate, Team, Me

• Come with the team that prepared some questions (they have my notes from the previous meetings for that)
• They present themselves quickly, ask a couple of questions
• Candidate can ask they own questions too

Interview 3

Who? Candidate, Boss

• When relevant, this is about "meet the CEO/head of X" stuff

From there we move to offer, etc.

Money

That's a tought one for me. One one side, I'm convinced that companies should "shoot first" (ie come with an amount or range) - mostly to avoid everyone losing time, if the expectation of one side are widely outside of the other range.

On the other side, in the small environments I work in, while we do have a job description, the person makes the job, not the other way around. This means I can generally accept someone too junior or too senior for the role or better at one aspect than other - it just means I'm going to shift the responsibilities around between the new hire, me and the team.

This makes giving actual meaningful range (ie not 50-150k€ or something stupid like that) complicated.

In addition, in Belgium you may end up with people under either employee or (fake) freelance status applying for the same position - and the way you frame the salary is very different from one case to the other.

In a nuthsell - I think companies where people fit a role with already 5+ people in it should have ranges and disclose them. Teams of 3-5 total with huge seniority or role differences are a bit a different topic.

Fun fact, when I'm applying as a freelance, I play that but on the opposite - which is that I'm going to disclose a range early in the process if the company did not - just to avoid losing time.

Juniors and Seniors

Ratio

I like coaching young devs... but you need to have your cadre in place. I generally feels like a 3/1 ratio is sane - that is three seniors for one junior.

This is consistent with the interests of the junior, the team and the company:

• As a junior, you want to have mentorship available - having several people around able to answer questions make sure it is (even with holidays, people being busy, etc)
• As a team, you want to mentor - but you also need to do your own tasks. Knowing that you are not the only person able to do it helps a lot.
• As a company, long term you want people to grow - so investing in the mentorship is very valuable... but long term you need to ship - so you want your team to spend a majority of their time on that

While this ration may seems high, if we look at demographic it should be easy to reach - depending on definitions, a junior developer will have less than 3 or maximum 5 years of experience. Out of a careers that is supposed to be 40 years long, that's between 1/10th and 1/8th of it - so should be easy to reach.

Hiring

Hiring a junior is making a bet on someone's capacity to learn and improve (massively) in delivery capacity in the next 6 to 24 months. Why? Because most people are not "operational" when they arrive - this is not a lack of will or a mistake in their training - it's just the way it is. Learning the ropes is something you do on the job - it has been for me and for everyone I know.

So we don't evaluate for what they know (we don't really care), but for what they can learn/how they think. It's tricky but it's the only thing that make sense.

What I found out being one of the most critical stuff is where they are on the "asking questions too early" vs "asking questions too late" spectrum:

• I want them to look for solutions, try stuff by themselves before asking
• I don't want them to spend two days banging their heads against a wall either
• I don't want to "checkup" on them too often as it's disturbing their work

Network effect

I've been hired by my network several time, and I've hired that way several times too. It's good and bad:

The Good

You're working with some "known values" - you know the people/companies the person has been working with/for, and this generally gives a good idea of the perimeter of the person capacity - ie you have an idea of the bottom line.

More often than not, it means hiring someone "similar" to me - so chances are good we are going to understand each other pretty easily.

All in all - it's a low risk option.

The Bad

It creates very homogoneous teams where everyone thinks a bit the same. As I grow older (damn) it also generate a sort of "cohort effect" of working with a bunch of other 40ish years old. We did mosly the same kind of stuff at the same time.

It creates a bit of an internal culture, but not always in a good way as it could stop "outsiders".

Now

I'm not blocked on any of those. I hired 5 people recently with no (or almost none) network effects and it worked great. I've also learned to diversity my hiring channels to reach people I would not normally be able too (ex: women via dedicated outreach program).

That does not means I'll never hire someone I know again, but at least it should come among a more diverse set of options.

Be honest

This is the other side of the coin to my advice to candidate - "be positive but don't lie". I apply this as the hiring manager. I try of course to paint the company/team in a good light (after all if I don't like it, I would not be there), but I stay honest. If things are complicated, I say it, if I don't know something I say I don't know, if we are not super mature in some aspect, I say it.

In the end, the candidate will join the company - and they'll make their own opinion. Painting an irrealist view of the company just increase the chance of the person leaving (possibly fast) something that's a loss for both sides.

Involve the team

That's probably the easiest one, and one I don't see applied a lot. Basically, bring the people that would be the candidate close collegues to one of the interview. Logic here is that both sides will learn something:

• The team can now have a say in the decision about a future colleague
• The candidate can forge a better idea of the people they're going to work with

What I usually do there is asking team member to present themselves and prepare a couple of questions, but the point is to trigger a conversation in the future team.

Technical evaluations

I'm generally wary of technical evaluations - mostly because the two most common types are for me problematic:

• Whiteboard: Asking someone to code something "live" looks artificial and stressful as hell to me - like it does not represent any real life situation (when is the last time you had to solve a problem alone, in 20 minutes, with someone looking at your back? Mine is University) and it may lead very good developers to fail.
• Take home exercise: I don't think we should ask people to work for free as part of our hiring process - so they can be ok if we speak about let's say 2 hours of work, but not more. Even there I think we should compensate for the time spent (but that's often complicated)

What I've done that I like:

• Ask the candidate to come with some code they have written, send it before, and walk us through it. It's their code, they picked it and we have a discussion similar to a PR one.
• Get the candidate to come work with the team for 3--5 days (paid of course): this is golden... but only works with freelances that have the time and status to do so. I did this only a couple of time, but generally by day 2 you know if you want to hire or not (and so does the candidate).
• For senior devs, ask them about good and bad experiences they have. I generally look for understanding of tradeoffs - our work is full of them, so it's all about understanding the ones they faced and the choices they made - not in terms of right or wrong but again it terms of what they did prioritize at the time and why.

Conclusion

I still think the interview process is broken - and I don't have a lot of ideas to fix it. My hiring process is still too much based on vibes (if not only mine) - but "factual" alternatives I've seen are generally equally problematic.

This being said, I've been mostly successful in my hiring process those last years - as in managed to create good teams that are working together quite well.

Opinions most welcome!

Content warning: this may be (even) more philosophical than usual.

What triggered those ramblings is me sharing something I often say "I cannot imagine managing a sales team" - as in "I can only see myself managing people doing a job I know - ie: software development".

Fact is, the friends I shared this with are both project managers (or product managers, does not matter here) of software teams, and none of them are coding.

They are also clearly successful - as in: they have earned the respect and trust of their developer colleagues, their customers & management, and are driving project home.

In another recent experience in a "CTO meet CEO" kind of "matching" event, I was told by one of the "CEO" people that out of the 7 people the've met that night on the "CTO" side I was the only one able and willing to code - which baffled me, especially in early stage startup - what are you doing to do as a "CTO" if you don't build?

So a bunch of feelings about this:

It's about me, it's not a rule for the world

First thing first - I could not see myself managing a team of people doing sales or bioengineering or something other. It does not means I think it's inherently bad for someone to do so.

I've seen people doing a really good job there (including the two friends I mention)

In other words: it's a rule for me, not for the world.

Software development is not (only) programming

Teams I work in/with are generally those kind of small mutlifonction teams - ie they include programmers but also designers or others.

To be more precise they include more functions than programming - usually product management, design, business analysis and a few other.

This may be a remain of the industry I started with - where all this roles were actually expected from a developer - or a trust that under a certain size teams of generalists tend to outperform specialists (due to being more flexible and requiring less steps between need and feature).

So - when I say jobs I understand it does not limit itself to "people writing code" - which also means I'd have no qualm with a software team being led by a devops or a designer either.

There is something weird in our industry

Look around. Medical teams are led by... doctors. Law firm have partners that are... lawyers. Architect offices are run by architects.

Programming teams are led by... project managers.

Why? Why is our industry so different than it can't promote or be led by one of their own? Are we programmers too stupid, too narrow minded, too introvert to do so?

I don't have the answer there, but you have to admit it's pecular.

Why it matters to me?

There are several aspects to this:

• Understanding: Having been there (and often still being there) means that when a colleague share a struggle I can at least say "I understand" - and mean it. It also mean I can help (even if I generally have other tasks).
• Qualified Opinion: When there is a decision to take, I can have a qualified (personal) opinion on the topic - instead of just having to rely on "who do I trust the most" or basic logic. It does not mean I don't listen to the team (I've often said "I prefer the 'green' option but Sonia thinks the 'red' one is better, and she's the specialist on this so I'd go with her opinion over mine") - just that I have something to bring to the table too.
• Technical representative: When I'm in a meeting with business people or management, my team trust me enough to represent them as being "one of them". I can also sometime directly give the technical view/consequence of a business decision (at other time I'll go back to the team to get more precise information).

This of course also make sense with my "pendulum" career (moving back and forth between developer and tech lead) - but that's not a necessity.

50 shades of team lead

Obiously, not every aspect of the "leadership" part is technical - far from it. Generally my role is about people management, priorization ("context and clarity") and technical autority. Only the third one requires that knowledge - but that means that if you are leading a team without technical knowledge, you then need to delegate that part to a technical person.

It does not seems as a problem, but I rarely see it done explicitely.

In the end

In the end - if it works, it works. "It works" meaning here the project goes forward and the various stakeholders (including the team obviously) are happy with it.

I could not imagine working any other way - but other people are different & have ways that works too. I've seen people that should not be leading dev teams due to their lack of technical skills - but again I've probably seen more people that should not be leading teams at all due to their lack of empathy - so it's may not always be the most important aspect

I'll not be talking about this idea of being able to only work a single day in the week - if you can, great for you, but I'm not there (yet?).

The One Day Week I refer to is a situation I now experienced at two different customers - due to my "time slicing" approach to freelancing (I've between 2 and 3 customers at the same time and I split my days between them) which is working a single day a week for a given customer/on a given project.

This lead me to some insights.

The days and the calendar

The most immediate impact is the wide difference between the work days and the calendar days. A small feature requiring 4 days of work is now a full month. A medium sized one of 10 is almost a quarter.

Assuming the rest of the project/company is not working on the same scheme (that's unlikely) and is going to continue to run on the other days, it make any task coming my way a very lengthy one

No time for getting in

Working on one day chunk means no or very limited time to "get in". Taking half a days to get back in stuff after a week of holidays will be (rightly so) considered ok.

Doing so every day of work, not.

It means organizing the work so that I can get "in" in less than an hour. Either because I've good notes (see later) or because I start something new that is well prepared/scoped.

Collaboration aspects

This also means that nothing I do can be blocking for colleagues - or the very very minimum. So even more than usual, well prepared, autonomous tasks are the only reasonable way of working.

Something I experienced already also is no regular meeting or any overhead - a two hours team meeting may be very reasonable out of a 40 hour week (that's 5% of the time) - much less so out of a 8 hour week (because it bumps to 25%).

Small tasks/deliveries

This is as usual the key - one day workweek only works if deliveries are split into single day or maximum couple of days tasks (two days is already half a month!).

While not easy (I always say that pretty much everything in software development can be made simple by splitting it into small pieces - but that splitting is generally quite difficult), the "one day workweek" context moves this from a "good thing" to a "mandatory one" - something that's generally beneficial to the team/organisation (short, regular deliveries).

Notes to self

Knowing that if I don't finish something completely by the evening I'll go back to it in a full week means taking a lot of notes to preserve context - I generally either have them in the task tracker (so I can easily get back where I was) or even directly as an appointment in my calendar scheduled at my next hour of work for that company.

This takes the form of a "letter to future me", with status but also/mostly ideas of next moves and "voiceover" of identified unknowns/things to try/etc.

The idea is really to have a "snapshot" of my mindset at a given time in order to restore it as fast as possible.

It's tough

Let's be honest, starting this was really tough. Each day means being very precise about the goal/output to make sure to have it done (or at least a viable PR) by the end of the day.

That put an unusual pressure on my "delivery or die" kind of freelance approach - I'm here to produce outcome, not code or even outputs - doing this on single days iteration is not easy.

It works (under certain conditions)

I've done this for some months at two different companies and I can confidently say that it can works - as is, generate real value for the project.

Among the conditions I'd require:

• Mature stakeholder with efficient communication - in one of the cases, I had something "finished" each week, so each new day started with a 20 minutes call with a stakeholder about the next need, followed by quick chat Q/As when needed, and a PR at the end of the day.
• Seniority: I would not have risked this early in my career. I'm playing on my seniority as in fitting in capability here.
• Dedicated area with limited contact surface with other developers: It's difficult to work this way on part of the code that are under heavy changes by the team

Things I've done using this scheme:

• Performance improvements
• Refactoring (with the idea it does not need to be done in one single session, as long as it can be merged after each, incrementally improving the situation)
• New (small) features, using feature toggles if needed to be able to deliver them in one day chunks

I also thing that the approach force me to challenge even more the "this cannot be split in deliverable parts" - because it usually is, if you dig a bit more.

I wish it was different, but it's not.

This means taking care of growing, getting (more) money, getting opportunities, etc.

Opportunities

In order to grow, you need opportunities - ie jobs, positions, tasks that are slightly above or at least different from the ones you are used to do. This is generally a question of balance - too much of the same and you are stagnating, too different and it can be very stressful.

The main point is: doing the same thing for 2, 3, 5 years is going to "cost" you in terms of career. There are very few chances any of us can find employment for doing the same thing for 40 years - so at some point you'll need to change/update, and the latter it is, the more painful it will be.

So you need opportunities for "new things" - either in your current job or by jumping ship.

If you work for a big company, that means moving internally, getting on larger/different projects, asking for horizontal moves.

Again, I don't believe this will happen "by itself" - so it means keeping track of what's happening in the company, building an internal network so that when something open you know about it and can make a move.

The downside of this is that most of the value of a network you build inside a company will be worth nothing once you move on - something that will most probably happen at some point. Again, 40 years is a very long time.

If the opportunities do not materialize at your current job (because there are none or you can't get them), then it's time to start looking around. This means possibly leaving "good" jobs "just" because they don't provide enough opportunities. It may feel weird or even wrong initially - but on the long term, it's a very pragmatic position.

Learning / Growing

This is very related to the previous point - you can't make your whole career on what you learned in your studies or at your first job. Seeing other things opens perspective. As a programmer, the usual example is language/ecosystems. While I understand some value of specialization, I think betting your career on single eco system is always a dangerous game. 40 years is long in term of technology - JavaScript will be legacy long before I'm retired, replaced by much "better"/"hyper" languages. I did use Pascal at some point, something that would be very difficult to find a job with today, etc, etc.

Same as above - when you stop learning, it's time to reevaluate your position.

Money

Generally speaking, I've not see a lot of examples of "work hard and you'll be recognized" (as in - get raises, etc). I do believe you need to do the work - but also that when that's done, you better come and ask for the money that comes with it.

In other words: it won't happen "by itself" and even if it does, you'll generally have more chance by asking - politely but firmly.

I don't think this is (generally) due to cruelty or greed - more to oversight. As a manager, it's easy to "forget" about the person that do the work & never complain/create problems - especially when you have crises to manage on a regular basis.

I would also advise against "sticker-like recognition" - giving you a title does not cost the company a dime but won't help anything but your ego. Getting "more responsibilities" is a scam if you don't get more money (it's basically thanking you for your work with... more work). Actual benefits are, well, money, or (more) days off, etc.

There is a also a high signal value in raises - it is something that cost the company something - which means it's the only way to validate that they indeed value you.

So when the time come (after a big project/realization or during the yearly 1-1 or anything like that) - come prepared to bring the topic on the table if the company does not. Come with the receipts about your work, about what you delivered and ideally about how this is different from last year/what you were hired for.

If the company deflect by saying they don't have the means, start by focusing on getting them to say (ideally write) that the raise is deserved - then go back to the "we can't afford that" by being "reasonable" (maybe you can have half now and half in six months). Again, go for written/precise/contractual statements - avoid the vague ones as much as possible.

It's about leverage

A lot of this come down to working toward a situation where you are generally more valuable to the company than they are to you. When you know you can find another job, having sane relationship with your boss/employer because much easier. Asking for a raise is easier when you have a good idea that you could get that amount - there or somewhere else.

The point is not to go "Give me X or I'll get them somewhere else" - that's unnecessary rude - but knowing you can helps a lot. The example is about money, the general one is "Is it more difficult for me to find another job or for the company to find another me?".

Once you've gotten through the "leaving, interviewing, signing another job" a couple of times, it become much easier and less scary - this is a skill too, one that can be practiced and improved upon.

It's about time

Careers are long - I started working at 23 (after university) - if I respect Belgium rules, I'm supposed to work until I'm 67. Which means that at 46, I'm only slightly past the "half time".

This makes the chance that you'll do your whole career in a single company, "just" moving "up" very unlikely. Which means most "company linked" elements have to be considered as "short term"

• My company have a very good training package - what if next year results are bad and this get shafted?
• My manager cares a lot about my learning path - what if she move to another company? Or is promoted herself?
• It's a huge investment, but it will make me very valuable to the company - what it the company is bought? Or go bankrupt?

Even facing the markets, the skills you have now and are in high demand on the market may be much less hot in 5 years - and irrelevant in 10. That's a long time - but it will still happen during your career time, and if you wait for it, you'll face a very difficult battle to reskill. Do you know about Clipper? It's a programming language. A bit before that I started my career it was suddenly the rage - everything was to be made in Clipper. Well, look at where it is today.

It's a long game - training and retraining gets easier as you do it - and more difficult when you don't.

Having to learn your second programming language at 45 after 20 years doing the same thing is going to be terrifying.

Practice working in uncharted waters. Take jobs that you know 80% (or 50%) of the required skills, not 100%. Take that new project that's different from the other.

Where it gets sad

I realized that this view (which is mostly the way I ended up behaving) is all about individuals and leverage and power dynamics - something not exactly aligned with my own values.

I'd like for our work relationships to be more about common good and interests of the many - but our industry generally scolds at unions or other forms of organization on the employee side - probably because we think we "don't need that". I'm quite sure we're going to regret it.

I found HR departments or equivalent to be generally at best hypocritical, at worse really dangerous (to employees) - I tend to agree with the general "HR is not your friend" sentiment.

Most people posting about the "glorious meritocracy" of the IT sector are generally delusional - they may be in privileged positions (like I am) now - but all of this could disappear at the next economic downturn.

Community

I still believe in communities - that is strength from groups. Join a union (if there is one active), join interest groups in your industry, especially if you are from a discriminated group. Talk with your colleagues, notably about money. Contrary to what people think, not talking about this with colleagues makes your position weaker, not stronger.

Requests to the company (for better work conditions or anything else) made by a group are generally much more powerful than the one made individually - hence have higher chances of success.

Networks does not have to stop at company boundaries - as time pass you'll probably have more colleagues in other companies than in your current one - you can leverage that too. I touched that point in The lone freelance and his 50 colleagues

Conclusion

Despite all this, I've mostly worked for and with nice people - my point here is not a cynic "everyone is bad/wants to take advantage of you" more a realization that my career is my own to manage. I've seen my goals align with a company goals several times already, and we made good journeys together.

I just know that it will end, and I've less qualms than I used to at being the one that decide that it's time.

I hear and read a lot about development teams efficiency - while I'm no specialist of the Theory Of Constraints, I've come to see most productivity issues as organizational in nature - much more often than technical (bad tools, languages, frameworks, etc).

To explain how this leads me to go against the industry tide and favor hiring full stack developers require a small trip back in time.

In the beginning we were all full stacks

When I started my career ("I was there 3000 year ago") about 20 years ago now, we were all "full stack developers" - we just did not use the term, as there was no other kind of developer anyway. That was before the ubiquity of the web too so we already had client & server in the same language (Java for me at the time).

Then the web came, and we were doing HTML with small bits of dynamic code in the middle of the pages using some template or all purpose language sprinkled in the middle. The web was all about Requests & Responses - in other words you send an URL and got back a page - which was unchanging until you put another url (directly or via a link or a form button).

JavaScript and Client-side logic

Then Netscape (the dominant browser at the time) enabled a small, quickly made language called "JavaScript" (because Java was popular at the time, so I looked like a good idea to name the new language "something like Java" - despite both language being pretty much unrelated).

This allowed to have code run directly in the browser, which means on the user's own machine (the "client"), which means we did not had to wait for a page reload to update small parts of the page. This made possible a bunch of small interaction, user feedback, etc (especially as CSS was nowhere as powerful as it is now, so JavaScript was the only way).

As JavaScript was not fully standardized across browsers (looking at you, Internet Explorer), some people stared JavaScript libraries to help manage this and a bunch of standard problems - jQuery (but also moo tools, Prototype, etc).

Then one more thing happened - the oddly named "XMLHTTPRequest" that allowed pages to call the server without reloading the page - which means you could (for example) show new messages as they arrived, even after the initial load of the page. This combined with the dynamic nature of JavaScript means we could run some "logic" on the front end and update the page accordingly - while or even before sending updates to the server.

But to this point it was still mostly "full stack developer work".

Rise of front end frameworks and specialization

What changed "everything" in terms of web development (team) organization was the emergence then prevalence of "front end frameworks" - things like Backbone, Angular or React (or Svelte, Vue, etc). Those technologies made a lot of the modern web app possible (Twitter, Facebook, etc). For smaller companies, it means making dynamic front end was made possible (by tools created by FAANG companies to solve problems they had - but that's another topic).

Suddenly it was no more about "sprinkling JavaScript" on a HTML front end served by a PHP/Java/C#/Python/Ruby/Whatever backend - the JavaScript front end was an app on its own, as complex (or more complex in some cases) than the backend. Learning and mastering those frameworks was no piece of cake either, so specialization started to happen - a split between "Backend Developers" (using one backend language and tacking business logic, DB relations, etc) and "Frontend Developers" (using a JavaScript framework and tackling fetching data from the server, showing it, managing interactions, etc).

Then we had to coin a work for those that were still doing everything - "Full Stack Developers" - in a world that was increasingly creating jobs for either front or backend (I've read somewhere that this was made "so that startups could justify doing a feature with 2 developers instead of one in a time of abundant capital").

Solo efficiency vs Team efficiency

So, how is this linked to team organization and Theory of Constraints?

Let's code a feature

In the "old/full stack" model, if you had a couple of features to implement, you put a developer on it to do it "end to end" - you of course have some kind of review cycle (technical, functional or both), but that was mostly it.

Now what you need is:

• Split the feature description between backend and frontend work (this may be trivial - or not, depending on the feature and level of preparation)
• Give the backend part to Sarah.
• Once Sarah is done, she can transfer it to her front end colleague Bob and go work on the next feature
• Bob do the front then move it to review/staging/QA

This works (sort of) but create a good bunch of new problems:

• What if Bob discover that something is missing (he needed this "network" field that Sarah did not include in the API) - he needs to go back to Sarah - but in the meantime, she's busy on the next backend feature, so she need to stop that, go back to the previous feature and make her update. Maybe it's not something missing, but that the way the API is organized is not practical from the front end, etc
• When QA arrive, if a problem is found that need to be solved on the backend, Sarah is probably days/weeks out of her work there - getting back there is going to be complicated
• When trouble happen the responsibility is split - it makes it complicated to solve a problem quickly

You can work around those things, of course (Sarah & Bob can work together for a while at the start of the feature, a first analysis can be done so that the API is negotiated from the start, etc) - but the flow becomes inevitably more complex. This can be compensated somewhat by the fact that both Sarah & Bob are specialists in their own areas and hence more efficient - but my experience show again that the flow is the primary factor of efficiency.

Team dynamics

Getting an higher view show that the situation is actually even worse than that - as we know need to acknowledge the frontend/backend divide not only in our work but also in our team organization. The previous team of 4 is now... 2 frontend and 2 backend? Or 3 and 1? Or 1 and 3? What if the proportion of backend versus frontend work is not stable in time (in my experience it is not - my current work at Farm For Good started full on Excel parsing, indicator computations etc... before moving toward a much more user focused set of functionalities)?

This means I'm not only losing time in the feature flow - I'm also losing a lot of flexibility in my team organization. Developers (me included) tend to take pride & ownership in their work - but this make it very difficult as it's always split in two. Team ownership is a thing, but it's again much more complex.

The endgame of that specialization logic is the kind of "software factory" you see at Big Companies - where each team is boxed between two walls and a feature go across all of them (like "system", "business logic", "interface", ...) - making sure no one is at any chance of feeling responsible for anything - and devoid of any chance of any cogs in the machine to improve on the Plan.

Advice

My ecosystem is generally small teams or companies - let's say one to ten developers. In those environments, I heavily recommend to go for full stack developers. Some kind of specialization is welcome (not everyone is at the same level in everything), but at least people able and willing to work on both parts.

This means I can assign end-to-end features to developers - which do not prevent them to go to the "local expert" on a specific topic. Frontend heavy features can still be assigned accordingly, etc.

The "split model" just creates far too many constraints on the delivery to be productive, once you factor the whole team.

Not everyone will be at ease with that - and that's ok (it's totally ok decide to specialize as a developer - I've seen a lot of people recommending it) - it just means those profiles are a bad match for such a team. Being very open and clear about how the team works should be part of any job opening - it's already complicated enough if you don't hide crucial information.

Opinions? Let me know on LinkedIn!

This post is a tad more technical than my usual ones. In the end, it's still about processes and even if you read this as a business person, understanding how development and developers work is still very important - and I'll try to keep this easy to follow.

If you know what git, pull requests and trunk based development are, you can jump directly to the next section.

Trunk Based What?

I've been reading about Trunk Based Development for a while (hi Thierry!), but never really applied it until recently. For those (developers or not) unfamiliar with this practice, a small explanation:

Development teams work using "Version Control" tools (usually "git") - those allow for all changes in the code to stay accessible for all eternity. In other words, any member of the team can at any time check any change done since the very first version of the system. This allow to "rollback" a change if needed among other features.

Developer use a local version of the software that works on their own machine. Once satisfied with their work, they can "push" their code to a central server (something like GitHub or Gitlab).

The open source world has initiated a practice called "Pull Request (or "branch") based development". In this model, every developer can work on a specific version of the software on their own, without impacting the work of the others. This is called a "branch". Branches can be pushed without impacting anyone else (the central server can have several branches open at the same time), so it allows this "parallel" work without requiring the code to stay on the developer's machine.

When the developer is satisfied with their work, they ask a colleague to check their code and "merge" it with the current version - this is called a Pull Request.

It brings a good slew of benefits, especially in "low trust" environments (if you maintain an open source project used by million - think WordPress - you don't want Joe from the basement that you never heard about before to make a huge change without a proper review) - generally a specific timing for review before going to production - the idea there is that "more eyes" tend to help fixing errors before they can even impact a user.

It also brings issues - the main being that it's "one more step" in the process - Sarah may be done with her new feature, but until Tom has time to review her code and approve it (possibly with several back and forth), it won't go to production - and code that is not in production does not deliver value to anyone - it's "work in progress" - something we try to minimize. It's the same problem in the end as the one I outlined in Why I hire Full Stack developers and why you should too - the more steps you have between a need and a feature in production, the more complicated it is to produce value on a regular pace.

Enter Trunk Based Development

Trunk Based Development moves away from that branch/request model. Every developer works on the "trunk" (the "main" branch). Anytime a developer "push" code, it is deployed to production. In other words, anytime any developer push an update, a script take the code and execute all required step to get it on the production machine - which can be several time a day per developer.

Trunk Based Development at OpenCompass

I've been working for OpenCompass for a couple of years - basically we compute a set of indicators about agroecological practices.

Team technical context

• Two senior developers, both part time (40%)
• Django + React web application
• A decent test suite on the backend (70% coverage, around one minute to run) - nothing on the front end
• Automated Deployment via GitHub Actions
• We get a broad product direction but have a lot of autonomy in how we deliver it (that includes UX and others)

So a rather classical situation, but on a very small, autonomous and senior team.

Results: two months in

We started working "the usual way" doing regular pull requests, reviews and merge.

Around two months ago, we decided to try to move to Trunk Based Development or to be more precise to no more require branches and pull request - so if one of us start something complex or experimental, we can still use those, we just don't mandate them anymore.

The only update we did to our setup is to run the test on push, and only deploy if the tests are successful. In other words, if the tests fail, the push still work, but it's not deployed (and the agreement when that happen is to fix it immediately)

What I can see:

• 400% more updates: We're clearly pushing more/faster updates. Going from around 15 deploy per month (4 per week) to around 15 per week - something like a 4x increase
• Shit happen: We're clearly breaking the production - but I'm not sure we do this more than before (code review in my experience is not that good at catching actual bugs).
• Fast recovery time: When we break, we generally get it back within 15 minutes.

We're not a telecom company nor a bank - while having anything broken is obviously bad, it's not killing our business as long as it recover fast enough.

Feelings: two months in

As a "subjective" benefit, I feel the general developer experience to be just smoother - anything that's on my laptop will be in production during the day, or the next morning at worse. I was always for small PRs/tasks, but knowing that I don't have to wait for a review to do the next part make those little changes much easier to do.

I realize now that even if I was able to split the 2 day task into 8 2-hours one, I would not have dare to inflict 8 PRs on my team in just two days - so I was limiting myself in that way, without really realizing it.

What's next?

We agreed that the practice is there to stay - I don't want to go back.

• I'd like to know "sooner" if something is broken: We have a sentry, so actual exception are going to be caught - the problem as usual is the front end.
• Better tests would be nice, but I'm not sure what this would mean: I'm no fan of UI testing (cypress and others are costly and brittle - a bad combination) - but I'll start a basic sanity suite on the frontend anyway.
• A "1 minute" test suite feels already quite long to me: Not sure I can get this much faster, especially as the application grow.
• Delayed reviews: In order to keep the "collective ownership", we decided to setup "package code reviews" every two weeks - one of us come with a feature/package area they worked on and give a tour to the other. We'll see how that work

Generally speaking, this is a nice demonstration of the "short cycles" are better - including in ways I did not expect.

Do try this at home - but mind the context

This works really well for us - but it depends on a good amount of context:

• Small team
• High seniority
• High autonomy
• Tolerance for mistakes (including in production)
• High trust environment

The point here is not that it can only work under this context, but that the practice (and it's success or failure) is at least heavily dependent on it.

For who ?

This is mainly an offer for companies large and small that are employing developers and interested in upskilling them. Whether it's young people you want to get up to speed or a seasoned team that could use help moving to the next technology, I can help by crafting a specific training for them.

My broad technological area is "web development" (backend, frontend, whatever) - if you think code training by a seasoned developer make sense, keep reading!

How I work

I'm not a trainer - I'm a senior developer. My view on development is that's it's a craft - not a science, not an art. As any craft, it can be taught but what it really require is practice. While explaining high level concepts has it's use, the majority of the training time should be people coding - not listening.

On a given day, I'd devote an hour to an hour and half on theory or examples - a good amount of them explained with code - the rest of the day is for the students to work on increasingly complex exercises crafted to make them understand and apply the concepts.

Some topics can be given in a couple of days (for example getting started in Pandas for people already familiar with Python) - some may require a week or even more (for example getting a whole team from jquery to modern front end development with - as an example - React and Tailwind).

A good group size is 6 to 12 - less and it become expensive but also less dynamic - more means I can't devote the attention that everyone deserve.

I don't only teach technology - I teach how to use it to produce actual value.

My experience

I've been developing software and helping other develop software for more than twenty years - mainly as a developer, but often as a tech lead or CTO. I'm focused on delivering value - the technical aspects are just a mean to an end, which is always some business goal.

I've also taught code to dozens or hundreds of people - as a public teacher, as a trainer in bootcamps like LeWagon, BlindCode or HackYourFuture. I've also crafted dedicated trainings for teams (mine or other people's).

I've worked in companies big and small, startups or big corporate (Swift, BNP, ...) alike.

I've seen a lot of things - and got some understanding about things that works in theory but not in practice - and sometime the other way around. My advice is always grounded in reality.

Some credits

Here are some feedbacks I've received as a teacher:

• BEST LEARNING EVER ! (caps theirs, not mine)
• Passionate and available teacher
• Very positive and upbeat which is nice for beginners. incredibly knowledgable.
• Best training in my career
• He was very good at breaking down problems, extremely patient and always available to help. I'm not sure I would have been able to finish the bootcamp without his help. I thought about giving up almost every week, but he did his best to keep me on board.

Let's talk

Intersted? - drop my a mail at martin@joyouscoding.com

Those last years I have a technical stack that has become my "reasonable default" - Postgres, Django, React.

There are a lot of reasons those tech are popular - they work well, are well maintained, and are a good fit for a good number of projects (generally speaking I don't think your project has any specific technical requirements - in other words, most tech stacks will fit most business needs).

While generally happy, I've been more and more concerned about advising that stack - or to be precise a specific part of it.

SPAs

Most front end development nowadays is happening in "SPAs" (Single Page Applications) - something coded in React, Angular, Svelte or Vue. Basically we cut the application in two parts:

• A backend interacting with the database and doing (most of) the business logic, coded in whatever backend language you have (Python, PHP, Java, .NET, ...). This backend expose data and operations as an API (a set of url that are sending back json)
• A front end with the screens and interaction, that calls the backend, coded in JavaScript.

This separation has always existed logically - but now we're doing two complete separate applications, with widely different technologies & frameworks.

There are of course benefits - it has become massively easier to create "interactions heavy" applications, and we saw extremely nice components library emerge (things like Shad, MaterialUI, etc). But there are downsides too.

SPA exist so that Startup could justify having two developers work on a feature instead of one (found on internet)

I'm not saying it's /that/ bad but that sentence hit a bit too close to home

The way before

Before the rise of those JavaScript framework, the way we did (web) interface was for the backend server to serve "HTML templates" - ie HTML files with some kind of specific tag able to insert dynamic contents - from JSP to Jinja to others. Any click on the page would generate a "full page reload", and dynamic elements needed to be done using some basic javascript (using things such as JQuery at the time). This worked quite well - and still does for a lot of standard applications.

The good and the bad

I was working on a sort of ecommerce at the time - and I started to worry. Working on both sides of the app was fun - but it took time, too. One day I did an experiment and coded a couple of the pages using standard Django templates.

Result was:

• A lot less code (single routing, no need to develop a full API then digest it, ...)
• Lighter/faster pages (no need for 3MB of JavaScript upfront)
• Simpler infrastructure (a back end server and a database)
• SEO working "out of the box"
• Smaller set of tech - which means easier to hire

What I missed ? The app was doing full page reloads - but the pages are fast (and by the way, so does Amazon). Some more interactivity would be nice, but that's easy to add with "progressive enhancement" (JavaScript that adds some behaviour) - for example to have a search working on the products shown on the page (AlpineJS is great for this).

My biggest loss here are the components libraries - but even there I found options such as TailGrids which offers components in HTML using Tailwind.

Note that this is in addition of not having to work with two developers each time as my comparison point is always a Full Stack Developer (me) - if this moves allow you to move from two dev on a feature to one, the benefits are much larger (in terms of flow).

Conclusion

As usual in tech, we find ourselves using technologies developed by and for extremely large players (Google, Facebook, etc). This attract a lot of interest, talks, packages, etc - but none of this make them by default good for the 99% of us (looking at you, Kubernetes). Solutions that were standard (such as templates) yesterday feels going against the wind nowadays.

I would not throw React(/Angular/...) away altogether - some applications benefit a lot from it. But I think going "two apps for one" by default is a mistake I won't make again.

If you are facing that choice, ask yourself what are the actual benefits - as the costs are quite high.

At a client, we're doing a web application that include a small use case for data reporting in the field (form + images). We've been working with a mobile first web app, but as time goes the connection issues (absence, low bandwidth, etc) had made clear we needed a "offline first" solution - in other words a mobile application.

Context

Some important things here as there is not such thing as a "best tech choice" in generic terms - everything is about "what's the best tech for us". In other words - I'll explain our process and ultimate choice, but a lot of it is about who we are.

• We're a small (2.2 FTE) dev team with a high level of seniority (20y+)
• Our expertise is mostly in web technologies, notably React that we use already in the same project, with styling using Tailwind
• We are operating in a trunk based development mode, deploying several times a day to production
• Our process is "Agile like" as in we are in close collaboration with our Product Owner & other stakeholder, with very fast validation cycle (our general appoach regarding any feature is "let's make the most simple option, release it and collect feedback before doing more")

With such a small team & a relatively clear goal, our first decision was to timebox the analysis time - once it was clear we had to pickup a tech we were on a Wednesday. Goal was to be decided for the next Monday last limit (we had several actions that required that decision, so we did not want to wait). All in all I thing we used between 4 and 8h of total person-time on this.

Non functional requirements

Based on this we listed some things we wanted:

• Good/great Developer Experience ("DX"): we want our users to have a good experience, but we also need something where the dev team has a good one - this comes with things such as productive, easy to test, etc
• Easy to deploy (even if in test mode) all the way to a user phone
• Easy to update (possibly several time a day)

Questions

I've tried to split the process into several steps showing our decision making

Doing it ourselves vs outsourcing it

That's an important one - facing a technology that's new to the team and used (at least initially) for a specific use case, the first logical question is "are we doing that ourselves". For the expected "yeah but if we outsource we need to pay those people". Sure. But we're costing money too, and we could use the freed time to work on other features.

While we value expertise (see below) our way of working is pretty much incompatible with the usual "agency model" where we would have to give a very clear specification, get it done and then stop. We could in theory bring a single freelancer in for this, but this model would not work well with maintenance and we need to be able to update the application ourselves.

We went against outsourcing because we wanted autonomy.

Now we added a fine print to this one by recommending to The Powers That Pays that we go for some hours of coaching by a freelancer senior in the exact technologies chosen. Our frame was not "someone with X years of experience" but "someone that released & maintained at least 3-5 applications in that technology". We care about production stories ("Tales from the trenches"), not just years of work.

Native vs Cross Platform

That one was easy. We don't have the cost to go for two different mobile application, and the benefits (exact match to each platform, etc) are of very low value versus the cost for at least the next 2 years (which is a very long time for us).

So we go cross platform.

Technologies to evaluate

A fast one - regarding cross platform mobile tech, we have only two real options: flutter and React Native. While some other exists (Kotlin Multi Platform, Xamarin, .NET Maui, Cordova), they are all either to old, too new or too niche to be considered.

We apply our baseline here regarding technologies which is we want something mature and widely used.

What made the rest of the process a bit more complex was that those two where obvious good choices (as in: we're confident we could deliver with both) - but we still had to pick and I was not ready for a dice roll yet.

Process

Our first action was to decide what could help us to decide.

We listed:

• Making sure we have our requirements as clear as possible
• Writing down the context

Then on the actions:

• Asking specialists from our network (people with actual production experience)
• Reading articles about each tech (focus on stories of teams implementing one)
• Feed our context to a couple of AI to get some insights

Our goal through all this was not to answer "which one is good" (they both are) nor "which one if the best" (it all depends) but "which one is the most adequate for us".

The specialists feedbacks

We reached in our networks for people with that "real world experience". My generally approach is to "shoot out" (in social networks or even on LinkedIn) for people that have experience and are ready to take a 30-60 minute call. I always offer to pay as those insights are very valuable and I feel that they should be compensated. For what it's worth, most people refuse to be paid for this kind of call, even when I tell them it won't lead to any contracting. In this case I was pretty clear that we intended to do the development ourselves.

Our main issue here is that almost no one has real world experience in both Flutter and React Native. Most experts were very happy with their own choices, but that did not lead to any help in terms of "picking" one.

Some good articles

Timing was on our side as Vercel published an article about their experience building their first mobile app using React Native. One sided (as they did not expand on the reasons of their choices) but pretty useful anyway for a lot of "little things" to make the app better.

The AI insights

We fed Claude with our context and options, and got quite a good report back:

React Native

Pros

• Minimal learning curve - Your team already knows React; RN uses similar patterns (JSX, hooks, components)
• JavaScript everywhere - Leverage existing web knowledge and potentially share code
• Expo advantages:
  • Excellent DX with instant updates via Expo G
  • OTA (Over-The-Air) updates - update multiple times daily without app store approval
  • Easy testing/deployment - share via QR code instantly
• Built-in offline/sync capabilities with libraries like WatermelonDB, AsyncStorage
• Mature ecosystem - More libraries, solutions for forms (react-hook-form), image handling, offline sync
• Styling familiarity - NativeWind (Tailwind for RN) available if desired
• Largest community - More Stack Overflow answers, tutorials, third-party packages  React Native

Cons

• "Write once, debug everywhere" - Platform-specific quirks can emerge
• Native module dependencies - Some libraries require ejecting from Expo
• Performance ceiling - Bridge architecture can be limiting (though improving with New Architecture)
• Not truly "like React" - No DOM, different components ( vs
  ), layout differences  ---

Flutter

Pros

• Consistent UI - Same rendering engine across platforms, fewer platform quirks
• Better performance - Direct compilation to native code, no bridge
• Hot reload - Excellent DX during development
• Web deployment
  • Can deploy as PWA from same codebase (though quality varies)
• Growing momentum - Strong backing from Google, improving ecosystem  Flutter -

Cons

• Steeper learning curve - Dart is a new language; different paradigm (widgets vs components)
• Team reskilling required - None of your devs know Flutter/Dart
• Smaller ecosystem - Fewer packages for offline sync, forms compared to JS ecosystem
• Update friction - Traditional app store deployment (no equivalent to Expo's OTA updates by default)
• No existing code reuse - Can't leverage React knowledge or any existing JS/TS code
• Web deployment caveat - Flutter web still has limitations (SEO, size, performance)

Developer summary

With this list in hand we had a first review, leaning toward React Native:

• OTA updates are a "killing" feature for us. Due to our deployment mode, being able to push updates without waiting for the App/Play Store validation is critical
• Flutter's pro about performance and consistent UI are mostly irrelevant to us.

This being said, several "downside" of Flutter were also irrelevant to us (we don't mind learning a new languages, and code reuse is not high on our current list).

Plot twist: the AI fight back

As a joke, one of our colleague decided to feed the context and the Claude answer to another AI, asking it to play the "Devils Advocate" feedback.

It did find several good pieces:

• Shorebird allow sort of OTA update in a Flutter app
• It mentioned several other edges such as having a "battery included" form system

even so, it pointed that going for Flutter was probably a good idea if we wanted Native look or were manipulating a lot of medias - problems that we don't have nor expect.

So we kept our initial choice.

Summary

We're going for React Native, probably with some packages we already use (react hook form and NativeWind for Tailwind like styling) - with an external coach/expert to help us make some of the remaining choices, including our offline architecture.

I guess I'll be able to write a conclusion in a few months - even if as usual, we'll never know what would have happened with the other choice.