La morte non è
nel non poter comunicare
ma nel non poter più essere compresi.

Death lies not
in not being able to communicate
but in no longer being understood.

From "Una disperata vitalità" (A desperate vitality) by Pier Paolo Pasolini

Yes, I must confess publicly that I am a developer facing a professional crisis.
I do not use this word, "crisis" in its common negative meaning, but in its etimological meaning.
What is a crisis, then? Crisis, from the ancient Greek verb κρίνειν (krínein), "to judge", is a moment where judgement is expected, where you are expected to discern between the good and bad that's happened so far to you - or that you have done.
A crisis is the grade 0 for a new enriching personal or professional start, i.e: a new awareness of your limits, skills and desires - a precious opportunity to grow.

I established myself as a professional developer relatively quickly, for a person with humanities background that almost never wrote a line of code in her life until her 40s.
I chose to code almost by chance. I liked the idea to be able to build something from scratch, that eventually could be used by many. Something useful, hopefully.
Coding is also a very relaxing activity for me, with the same quality of mathematical games or puzzles.
The challenge of building something complex and, when it succeeds, the rightful pride you can have by it, was and still is very appealing to me - as I think for many of you, too.
Problems start happening, though, when you code professionally.
If you code for a company, fairly obviously the motivation behind your coding should align with the goals of the company you are working for.
I recently failed finding motivation in coding, while working for some companies, both as contract or permanent developer.
I found that my coding was deeply affected by the personal and group dynamics of the web team I was in.

These are the things that annoyed me the most and eventually polluted my motivation for work, in a way that I did not even care to be productive at all.

1. Lack of social interaction

Nothing is sadder than feeling alone in a group. You sit in a very silent office, where everyone is just working at his or her task with earphones on and if you ask something, the usual answer is something reducible to "I do not have time for that".
The paradox is that most companies will heartily recommend you to "ask if you are not sure", particularly if you are the newest employee, no matter your seniority.
For 90% of them that is a lie.
The less you ask, the better it is.

Ok, I get that. I can google/research the company knowledge base hoping to find answers. I may hope for more social interaction at lunch break, possibly? Then lunch break happens and the silent developers eat silently their lunch in front of you, muttering one word answers to your attempts at starting a simple conversation.
As for my response: I am a conversation starter, normally, so my response to a situation with manifest "lack of social interaction" was to try to interact nevertheless. But that proved to be exhausting and demotivating after a while.
You wake up, you commute, sometimes for 40/60 mins, to get to a silent office, where you are supposed to work in isolation and isolated, and you feel you are just a peg in a gear, near other silent pegs.

2. Lack of curiosity

Who are you? What are your interests in coding? Do you have interests at all, beyond coding?
I normally ask my colleagues what they do, how they spend their weekends, what their interests are in coding and beyond. Management is rarely curious to know your interests, let alone aspirations, even in coding. Your colleagues almost never, as well.
That is a pity, though. A curious and lively developer needs curiosity as well, to feel appreciated in her/his job. In a workplace with no social interaction, well, there is also a lack of curiosity, so the two cases are very similar and bound to produce the same effect.

3. Unbalanced expectations

The engineering manager asks you, the newest employee, to be more socially proactive and suggests you to invite your colleagues to lunch together at lunch break. You find it to be an idea, although no-one invited you to lunch together since you started working for the company, so you invite your colleagues to lunch together, nevertheless, and what you get is a "oh no, thanks" with different explanations.
Ok, you can still try everyday, until you break the vicious circle of silence and asociality, but that is exhausting and demotivating. And again with the feeling of being a peg in a gear...and your coding suffers from that, you code with less energy, with less motivation, you just do the minimum acceptable.

4. Lack of culture

I believe that being a nerd is not about what you have knowledge of, but about how deep your need for knowledge is - any knowledge. About intellectual and cultural curiosity, in its broader meaning.
In the companies I worked for, I rarely found love for culture. In the luckiest cases, I could find at least a cultural curiosity in some colleagues.

If you are a cultural enthusiast like me, you can get easily demotivated, when you hear your colleagues saying "it is good to have books at home, for decoration" or when your manager interrupts you abruptly, while you praise the presence of great art museums in Berlin to the newest onboarded, who just relocated from US, only to suggest the visit to the Technical Museum, instead.

I get it.
For many companies and colleagues, art and culture do not match with coding, they are just distractions or interests you should not mention at work - and if you mention them at work, well, that is felt almost as inappropriate as mentioning your favorite sex position in a daily standup.

Honestly, I am fed up.
I am fed up of the way culture and culture enthusiasts are being bullied and marginalized, in any professional sector - except of course for the culture sector (and sometimes even there).

It is funny, though, that in a culture friendly environment, I proved to code with more enthusiasm.
In my most utopian dreams, I dream of a company that, beyond peanuts and fresh fruit, provides annual subscriptions to the city museums and has a room for playing piano or guitar or, why not, drawing.
How amazing it would be, to have a company organizing drama workshops instead of minigolf, as optional after work activities, for instance. That would be awesome, wouldn't it?

Lots of companies offer gym subscriptions to provide care for the physical health of their employees and they are absolutely right to do so! But what about their intellectual health?

Coding is a very stressful and exhausting intellectual activity, while art in all its forms is a proven cerebral relief and a well known psychological therapy (hey, engineering managers, have you ever heard about art therapy? Music therapy? And instead, even this year, your company will host the annual minigolf championship. Sicut erat demonstrandum)

5. Pre-existing bad code or bad development processes

Enough with the soft skills and "small talk", let's get technical.
In one of her recent interventions, Sandi Metz, the famous Ruby guru, mentioned a psychological study that listed the main reasons of stress and demotivation among developers. At the top of this list, bad code, technical debt, bad development processes.
Unnecessary complicated code structure, Cerberus-like repos, with no clear architecture but many heads (and then you get to know that no, the big multinational company you are working for never hired a software architect for its big portal, every developer just contributed to its tweaked complexity with his or her own ideas and style).
No flat hierarchies, waterfall methodologies faked as "agile".

In my experience, you can tell if a company is adopting a waterfall methodology by its project management tool - usually Jira - and by the number of steps before a ticket is considered closed. If it is more than 4/5, with many steps requiring approval, well, most likely a lot of micromanagement happens in the web team. Sometimes with cause - for instance, if the company is in a highly security-sensitive sector, like banking, or if the production environment is so old and burdened with technical debt, to explode with errors for the minimum change - but sometimes not.
If I cannot say to my engineering manager or CTO: I am not a junior coder anymore, let me code! Trust me, empower me with responsibility, instead of loading me with the fear of breaking everything and you will see the results , as it is most likely, I will have to hold tight, accept all the micromanagement/bad practices in my web team and go on coding the best I can. Right. So, what happens?

I submit my PR.
No one is interacting in Jira.
No comments by fellow developers about reviewing the code or by QA testers.

In any case, if my work environment is already one poor of social interaction - see points 1 and 2 - why should Jira be suddenly populated with interactions? It will not, of course, and with cause.

So I wait, and wait for the hyppos to review, comment and finally approve a PR, that I submitted more than a week ago.
And in the meanwhile my motivation decreases, while old tickets keep crawling from a sprint to another.

I want to fail fast, and succeed as fast and instead they do not let me.

Not to mention that I am not bound to be in any case productive, if there are many dead times due to micromanagement/bad processes.

So, I lose the productive "rhythm" and I will not be of any help, not to myself or to the company. And my motivation decreseases quickly, very quickly, particularly if I am that kind of developer, whose main reason to code is to build something helpful.

Conclusion

In my professional odyssey, I came to a not so obvious conclusion, out of my experiences.
A developer is not a coding machine - yet - but a human being, with her or his expectations, interests, weak and strong psychological features. Colleagues and managers are human beings, too, with their strong or weak personal points.
Technical or managing processes reflect the main working environment, made of individuals, aka human beings. They are the sum or even the multiplication of the defects or virtues of a company's employees and their impact is proportional with the responsibility of each working individual. That is to say, that the personal or psychological or cultural attitudes of managers will inevitably have a greater impact on the working environment than those of employees with no decision power.
A developer who lands a job in a toxic working environment can try to hold tight until it is possible, he or she may even try to improve some working processes, but in the end will never be able to change it.
Unfortunately, I have experienced that on my own "professional skin".

I cannot change a bad, asocial or toxic working environment.
But I can change my attitude towards this.

I will always try to give my best, in terms of good, sound, clean code, as a developer, but also in terms of good, positive, generous and caring behavior towards my colleagues, as a human being.
For me, one cannot succeed without the other.

Hélas, I am also a critical spirit, too, though and it is a great defect to be a critical spirit, that is to say, to never stop judging what you do, what others do and expect of you.

Up until now, I tried to practice the well known sayings: "Fake it until you make it" or, worse, "Never complain, never explain".

Sorry, I cannot fake it anymore. And sorry if I complained, I am glad I explained my demotivation to you all.

It is up to me, now, to be more selective with my potential employers, already at job interviews. I know now what to ask, in order to have a clue about their working environment. How they use Jira, or how much technical debt they have, for instance. Or maybe I will ask them if they know their developers' hobbies - if an engineering manager or CTO does not know that, I guess it is a red flag for lack of social interaction/curiosity.

I need to have clear in mind what I do not want and I do not like, to focus on what I want.

And if that means a longer job search, well, I will be patient.
I will find more time to grow my personal projects and I will finally have fun in coding again.