Apr 7, 2019
think-cell Response
7yDear former colleague,
Thank you for taking the time to write a detailed review, pointing out many of the positive aspects that make think-cell a unique and pleasant place to work at, including “no meetings, no deadlines, no management-nonsense of any kind”. This is how I intend it to be, and I am glad that your experience reflects that. I am sorry to hear that, despite these and other benefits, you did not have a good experience at think-cell.
Evaluating a new employee and deciding whether to keep her or him for a permanent position is challenging. This evaluation process, in particular when I am leaning towards the "won't keep" side, is bound to be emotionally less than ideal. On one hand I do not want to put the new employee under undue emotional stress, on the other hand I have to convey a sense of urgency to perform better, so she or he has a fair chance to show the best of her or his abilities before making my decision. For example, sometimes I may want to see how much the employee can glean from a given code base, without being given outside help.
Every project a new employee embarks on has a primary mentor, either me or another experienced developer. If you only stayed for a short period, you probably did not get beyond your first project, which is likely the reason you kept working with me rather than other developers. Still, groups of developers go to lunch every day and they publicly invite everyone who might be interested to join. Usually, there is also an organized lunch to welcome new hires, which is meant to get you in touch with your colleagues.
Regarding static analysis, we tried some of the leading products, but with the very functional-style code which makes heavy use of our range library, the products produced tons of false positives, but nothing meaningful. We tried Clang Format on our code, but even after modifying its code to better fit our coding style, found that formatting contains too much semantics to be made automatic. There are only a few coding guidelines which are well lintable, like adding exception specifiers to all functions or using struct instead of class. The rest, like inlining single call functions, are more structural and I have trouble finding a linter for them. We do have a dedicated developer refactoring the code to the latest coding guidelines, so adherence of the code is very good. It is easy to find an example of how things should be done.
In the by now 17 year history of the company, only 2 developers made the decision themselves to leave the company, everyone else is still here. So think-cell may be somewhat unusual, but I still think it is a very good place to work at.
I wish you good luck for your future.
Arno