Here are some updates, I am on a new contract since three months now. I changed my settings. This is the story of what happened to me after my last introspective dilemma. And my discovery of a new type of developers. Wanna read about that?
For the past year I have been working in a standard big company. Full Windows. V cycle software release workflow. Very traditional software production. Despite the appearances I have learned a lot, and it was not bad at all. Not to mention that, such experience is very valuable during developers pizza parties. You can describe your antique stack and complain about it. “Hooou, you know my versioning system is CVS, C-V-S !!!” “And there are no tests at all, every time I have to push into production I need to take anti-stress pills !!!” This experience made me realize how much developers comfort matters.
Developers comfort
It is not ok to come and work in a place where it is painful to do your job. Concretely, this place had an IT management that absolutely didn’t care about the technical teams. It’s exactly like you would picture it, managers in their suits and features asked by who knows who. For example, we needed to translate our application in seven languages and since the website was very unmaintainable the translation would first cost a total redo over. Instead of allocating the budget or the time to do that, the management asked us to evaluate how long it would take us to just duplicate the website seven times. Ouch. Clearly their priority was not for the technique even if they were IT managers.
I understood then that I was really not in the right place. And I realized they had hired me just because the application was such in a bad shape that they needed someone with experience to understand it to work on it. For some time, I reflected, am I some kind of doctor for code? Should I cure the application? Wouldn’t I be some kind of coward if I just left? So, I cured it like I could, I optimized it where I could, but the real cure would be to kill it and resuscitate it as tragic as it sounds. So in the end, I left. I think that when you find yourself in this kind of situation, if you are in an environment where change is possible, you should try to change things and use your expertise to improve what exists. But if you are in an environment where change is very hard because the management is rigid and could not care less, you’d better leave.
Ultimately that’s what makes developers leave I think: lack of comfort, lack of flexibility, lack of care. Yes, developers need care! If you put them in an environment where they can’t change anything, they will leave. Or if they really can’t change anything, the place had better be perfect and comfortable, meaning they can have their preferred environment, tests, logs, continuous integration, documentation, accessible infrastructure and all that jazz. It is indeed compulsive for a developer to want to change things when they’re not comfortable, and they really do it. Lack of care means that you don’t understand that and you lock them in some kind of cage hoping they will produce work. Lack of comfort means you make it hard for them to work, for example if their environment is hell to setup, or if sysadmin stuff become their problem. Lack of flexibility means that they can’t contribute with their ideas or take initiatives.
That said, I have learned a lot in the sense that now I know what bad practices are. I have a full catalog of what not to do when you design software. Until then, I had not worked on existing applications but I had always been at the start of a new project. So we always applied the good practices. Now I see why a bad practice is bad, and what it costs in the end. I understand perfectly what technical debt is. It helps me have an opinion on how things are done. Learn from the bad to get better, that’s what I take from this experience.
New settings
And so I left. Only to land in the complete opposite setting. I got lucky. It was like I was trying to breathe under water, and then I discovered air. No kidding. Basically, I landed in a place where they have all that was missing from where I was: tests, logs, continuous integration, Linux, code reviews (although let’s not cheer at this too much), pizza parties, cool people, well, the hackers decorum. However, this came with many things I had to adjust to:
1. the commit style
First, the commits style. On my first commit, I got this comment from the code police guy:
Your commits are wrong.
Your commits are wrong.
We work with Github so the commits are no longer private but they are instead splashed over the Github interface for everyone to see. I had to adjust the message I put in my commits against those conventions. It’s not a bad thing. It only made me realize I had just entered the world of social coding. When I started, it made me feel I was coding under surveillance. But now I got used to it. Coming from my ancestral stack, I just needed to make some adjustments. Another big adjustment was the code review session.
2. the code review circus
A code review is just showing another developer your code so that he or she can tell you what conventions to respect or how you could improve your code. It is very useful to maintain a certain code quality. In my sense the code review should only serve that purpose, check that you respect the coding standards of the team. But as it turned out, there was no documentation on standards so my experience of it was not so good.
Basically, I had to review with a guy who blatantly told me he couldn’t care less about the names of variables (w.h.a.t), so all my comments to make his code more expressive were of little importance and just detail. Then, often it would end up in an unsolvable debate. One would argue that he would have done it his way, the other would argue exactly the same thing. For example one would use dependency injection, the other wouldn’t. It’s as if two writers argued on how to write a sentence. One would say “John is dead”, the other would say “John silently expired his last breath”. So then what? The greater problem arises when they’re not capable of giving you any arguments, but they just say “because I assure you, it is better like that (I know more than you)”. Ugghh. In the end you’ve got to call someone with bigger experience that you’re supposed to trust because, well, they know. Some decisions though, should already be documented with pros and cons, it should not be just a gut feeling thing anymore. The way I deal with this is to put arguments forward, it’s unbeatable.
That said, code reviews can still be very good to learn from other developers, it can help you enrich your coding style with theirs. Just take the best from it.
3. the no bullshit talk
Then, with the “I know more than you” style, also comes the no bullshit fashion. Indeed, I had also to adjust to the no bullshit talk. Some developers take pride in being the no bullshit kind. What does that mean? It means they just say what needs to be said with no bullshit. I have no problem with that except that often when they think they’re no bullshit, they’re actually full douchebags. Sorry, but it’s true ! They mistake bad communication for honesty. As a result, instead of being constructive they just say suff like “your idea brings nothing”, or “what they did is stupid”. This bizarre attitude also often comes attached with the strange opinionated behaviour.
4. the opinionated attitude
When you read technical articles online, you often read in the developer’s description “opinionated developer (woohoo!)”, it is indeed waved like a flag of pride. I never really understood what it meant until now. Now I know, an opinionated developer is just someone who will give you his (negative) opinion on every subject about software! Say, you comment on how practical AngularJs is, they will answer “of course, it is optimized for bad developers” and inevitably they will continue on lecturing you about the “boilerplate” vs “non-boilerplate”. They will also have rigid opinions about some programming patterns, like functional programming, dependency injection, typed vs not-typed, etc. I’ve never crossed developers with so many strong opinions about the code. They make it sound like they have a dozen years of experience when you soon realize they don’t. Having opinions is fine, always pulling them out about everything is just tiring for everyone. Especially when they lack arguments. The way I deal with this is just asking them for arguments, and drop the conversation if they don’t have any.
So those are the major new things I had to adapt to. At least those are all signs that I am surrounded by people who love software, which is a great thing. It is quite an upgrade, and I am for now happy about it. Adapting has kept me busy, but I am back for new articles!
